Kas yra programinės įrangos testuotojas?
Programinės įrangos testuotojas padeda komandai suprasti, ar produktas veikia taip, kaip sutarta, kokių problemų dar liko ir ką jos reiškia vartotojui. Jo darbo rezultatas – aiškūs patikrinimai, atkuriami klaidų aprašymai ir informacija sprendimui dėl produkto išleidimo. Vien paspaudyti mygtukus neužtenka: reikia suprasti, ką sistema turėtų daryti ir kokiomis aplinkybėmis ji gali suklysti.
Darbo skelbimuose ieškok pavadinimų Software Tester, QA Tester, QA Analyst, Manual QA, Test Engineer. Pavadinimas ne visada tiksliai parodo atsakomybes. Vienoje komandoje QA daugiausia tikrina rankiniu būdu, kitoje rašo automatinius testus. BLS profesijos apraše išskiriami bandymų planai, rizikų nustatymas, defektų dokumentavimas ir rezultatų perdavimas kūrėjams. Tai JAV profesijos aprašas, o ne Lietuvos atlyginimų šaltinis.[1]
Ką testuotojas veikia per darbo dieną?
Įsivaizduok komandą, kuriančią rezervacijų sistemą. Atsirado galimybė atšaukti užsakymą. Testuotojas pirmiausia išsiaiškina taisykles: iki kada galima atšaukti, kas nutinka mokėjimui ir ką mato administratorius. Tada paruošia duomenis, patikrina skirtingus atvejus ir aptaria neaiškumus.
- Peržiūri naują užduotį ir jos priėmimo kriterijus.
- Su programuotoju ar produkto vadovu suderina neaprašytas situacijas.
- Pasirenka svarbiausias rizikas ir suplanuoja patikrinimus.
- Testuoja naršyklėje, telefone arba per API.
- Registruoja problemą su įrodymais ir pakartojimo žingsniais.
- Patikrina pataisymą ir gretimas funkcijas.
- Trumpai praneša, kas išbandyta ir ko dar nežinome.
Pavyzdinė dienos struktūra: ryte komandos aptarimas ir rizikų planas, vėliau du ilgesni testavimo blokai, dienos pabaigoje pataisymų patikra bei rezultatų santrauka. Tai planavimo pavyzdys, o ne visoms įmonėms galiojantis grafikas.
Rankinis testavimas, automatizavimas ir QA: kuo skiriasi?
| Kryptis | Pagrindinis darbas | Ką parodyti portfolio |
|---|---|---|
| Rankinis testavimas | Tirti elgesį, tikrinti scenarijus ir aprašyti problemas | Rizikų sąrašą, testų atvejus, gerus defektų aprašus |
| Automatizuotas testavimas | Kurti ir prižiūrėti pakartojamus programinius patikrinimus | Nedidelį testų projektą su paleidimo instrukcija |
| API testavimas | Tikrinti užklausas, atsakymus ir verslo taisykles be vartotojo sąsajos | Užklausų rinkinį ir aiškius tikėtinus rezultatus |
| Kokybės užtikrinimas | Gerinti procesą, kad klaidų atsirastų mažiau | Siūlymą, kaip tikrinti reikalavimus arba leidimo pasirengimą |
Pradedančiajam verta mokytis testavimo mąstymo ir tik tada automatizuoti suprantamus patikrinimus. Įrankis nepakeičia sprendimo, ką ir kodėl tikrinti. Automatizavimas taip pat reikalauja priežiūros, kai produktas keičiasi.
Kam ši profesija gali tikti?
- Pastebi neatitikimus ir nori suprasti jų priežastį.
- Gali kelis kartus pakartoti tą patį veiksmą, tiksliai keisdamas vieną sąlygą.
- Moki raštu paaiškinti problemą be kaltinimų.
- Nebijai pasakyti „dar nežinau“ ir pasiūlyti, kaip patikrinti.
- Domiesi vartotojo užduotimi, o ne vien ekrano išvaizda.
Gali būti sunku, jei itin nemėgsti dokumentavimo, nepatinka neapibrėžtumas arba norisi, kad kiekviena darbo diena būtų visiškai kitokia. Kita vertus, tvarkingas žmogus nebūtinai iš karto bus geras testuotojas: reikės išmokti kelti hipotezes ir atskirti svarbią riziką nuo kosmetinio trūkumo.
Palyginimui perskaityk techninės pagalbos specialisto ir svetainių kūrėjo gidus. Pirmasis dažniau sprendžia jau iškilusią vartotojo problemą, antrasis įgyvendina produktą.
Kokių įgūdžių reikia pradžiai?
Testavimo pagrindai
Išmok suskaidyti reikalavimą į patikrinamas sąlygas. Pavyzdžiui, „amžius nuo 18 metų“ skatina tikrinti reikšmes žemiau ribos, ties ja ir virš jos. Taip pat svarbu atskirti pataisymo patikrą nuo regresijos: pirmoji tikrina konkretų sutaisytą defektą, antroji ieško nepageidaujamo poveikio kitoms funkcijoms. ISTQB pagrindų programa apima testavimo technikas, procesą ir defektų valdymą.[2]
Techninis raštingumas
- Naršyklės kūrėjo įrankiai: klaidų pranešimai ir tinklo užklausos.
- HTTP bei JSON pagrindai ir supratimas, kas yra API.
- Duomenų bazės pagrindai; paprastos SQL užklausos tik leidžiamoje aplinkoje.
- Versijų supratimas: kokį leidimą ir kokioje aplinkoje tikrinai.
- Git pagrindai, kai pradedi dirbti su automatinių testų kodu.
Bendravimas
Pranešimas „neveikia“ perkelia visą tyrimą kolegai. Pranešimas „bandomojoje versijoje X po antro paspaudimo sukuriamos dvi rezervacijos“ suteikia kryptį. Mokykis skirti pastebėjimą nuo savo spėjimo apie priežastį.
Ar reikia mokėti programuoti?
Rankinio testavimo pradžiai nebūtina iš karto rašyti sudėtingo kodo. Tačiau techninės žinios didina savarankiškumą, o automatizavimo pozicijose programavimas yra darbo dalis. Rinkis vieną kalbą pagal dominančius skelbimus ir įrankius, pavyzdžiui, JavaScript arba TypeScript naršyklės testams.
Pradinis tikslas – suprasti kintamuosius, sąlygas, funkcijas, kolekcijas ir asinchroninius veiksmus. Nukopijuotas testas, kurio negali paaiškinti, nėra stiprus portfolio įrodymas. Geriau trys aiškūs testai, kuriuos moki pataisyti, negu šimtas sugeneruotų patikrinimų.
Kokių įrankių pakanka mokantis?
Pirmam projektui pakanka naršyklės, teksto redaktoriaus ir lentelės. Defektų valdymo įrankį gali pakeisti tvarkingas dokumentas. Vėliau pridėk API klientą, Git ir vieną automatizavimo sistemą.
Playwright skirtas žiniatinklio programų testams ir palaiko Chromium, Firefox bei WebKit. Oficialioje pradžios instrukcijoje yra projekto sukūrimas, testų paleidimas ir rezultatų ataskaita. Prieš diegdamas tikrink aktualius sistemos reikalavimus.[3]
- Pradžia: rankinių patikrinimų lentelė ir klaidų registras.
- Kitas žingsnis: užklausų bei atsakymų patikrinimai bandomajame API.
- Automatizavimas: keli pagrindinio vartotojo kelio testai.
- Komandinis darbas: pakeitimų istorija ir paleidimas bendroje aplinkoje.
Kaip atrodo geras klaidos aprašymas?
Žemiau – išgalvotas mokymosi pavyzdys. Jis nerodo realios svetainės gedimo.
Pavadinimas: du kartus paspaudus „Rezervuoti“, atsiranda dvi vienodos rezervacijos.
Aplinka: mokomoji sistema, versija 0.3, bandomoji paskyra, naršyklės versija užrašyta bandymo metu.
Žingsniai: pasirinkti laisvą laiką; užpildyti privalomus laukus; du kartus greitai paspausti patvirtinimą; atverti rezervacijų sąrašą.
Tikėtasi: viena rezervacija ir aiškus patvirtinimas. Gauta: dvi rezervacijos tam pačiam laikui.
Įrodymai: ekrano įrašas su išgalvotais duomenimis, bandymo laikas ir užklausų identifikatoriai. Atkuriamumas: trys iš trijų bandymų.
Pridėk poveikį vartotojui, bet neišgalvok finansinės žalos. Rimtumą ir taisymo prioritetą aptark su komanda: jie nėra tas pats. Problema gali būti rimta, bet nepatekti į artimiausią leidimą, jei pažeidžiama funkcija dar nepasiekiama vartotojams.
Ką tikrinti, kai viskam neužtenka laiko?
Pradėk nuo to, kas svarbiausia produkto paskirčiai. Rezervacijų sistemoje tai gali būti tinkamas laikas, teisingas užsakymo statusas ir apsauga nuo pasikartojimo. Turinio svetainėje – turinio pasiekiamumas, navigacija ir formos. Sudaryk sąrašą „poveikis × tikėtinumas“ ir paaiškink pasirinkimą.
- Kas pasikeitė šiame leidime?
- Kokios funkcijos priklauso nuo pakeistos dalies?
- Kas nutiktų praradus ryšį arba pakartojus veiksmą?
- Ar matoma klaida, kai įvestis netinkama?
- Kokių patikrinimų neatlikome ir kodėl?
Testų skaičius savaime nėra kokybės įrodymas. Vertingesnė ataskaita pasako, kurias svarbias rizikas patikrinai ir kokios liko atviros.
Prieinamumas ir saugumo ribos
Pradinei prieinamumo patikrai išbandyk puslapį klaviatūra, pažiūrėk, ar aiškiai matomas fokusas, ar formų laukai turi pavadinimus ir ar turinys įskaitomas padidinus vaizdą. W3C „Easy Checks“ yra pirmoji apžvalga; sėkmingai atliktas trumpas sąrašas nereiškia pilno prieinamumo atitikties įvertinimo.[4]
Saugumo testavimas yra atskira atsakomybė. Mokykis savo ar specialiai mokymui skirtoje sistemoje. Svetainės viešumas nesuteikia leidimo bandyti apeiti prisijungimo, teisių ar apkrauti serverio. OWASP pateikia struktūruotą žiniatinklio saugumo testavimo vadovą; realiame projekte pirmiausia turi būti sutarta apimtis ir leidimas.[5]
Kaip susikurti portfolio be darbo patirties?
Sukurk vieną užbaigtą mini projektą. Pasirink mokomąją rezervacijų, užduočių arba prekių krepšelio sistemą. Aiškiai parašyk, kad tai savarankiška mokymosi užduotis. Nepristatyk savęs kaip tikro produkto darbuotojo ar užsakovo.
- Viename puslapyje aprašyk produkto tikslą ir patikrinimo ribas.
- Išskirk penkias svarbiausias rizikas.
- Paruošk 10–15 skirtingų testų, įskaitant ribas ir klaidingą įvestį.
- Užfiksuok tikrus rezultatus. Jei defekto neradai, jo neišgalvok.
- Parenk vieną gerai dokumentuotą problemą arba neaiškaus reikalavimo klausimą.
- Pridėk trumpą santrauką: kas patikrinta, kas liko ir ką darytum toliau.
Jei kuri automatinius testus, pridėk paleidimo instrukciją, priklausomybes ir trumpą paaiškinimą, kodėl pasirinkai tuos scenarijus. Playwright rekomenduoja tikrinti vartotojui matomą elgesį, izoliuoti testus ir naudoti patikimus elementų parinkimo būdus.[6]
Praktinė užduotis: pirmas testavimo planas
Atsisiųsti užduotį ir pildomą planą ↗
Skirk 60–90 minučių. Užduotis – patikrinti mokomąją registracijos formą. Reikalavimai: vardas privalomas, el. paštas privalomas, sutikimas su taisyklėmis privalomas, po sėkmės rodoma viena patvirtinimo žinutė. Jei neturi veikiančios mokomosios sistemos, paruošk planą ir rezultatų laukelyje rašyk „nevykdyta“.
- Numatyk teisingą, tuščią ir klaidingą įvestį.
- Aprašyk dvigubo pateikimo ir nutrūkusio ryšio atvejus.
- Pridėk klaviatūros bei mažo ekrano patikrinimą.
- Atskirk tikėtiną rezultatą nuo faktiškai stebėto.
- Užrašyk bent du klausimus apie neaiškius reikalavimus.
Įsivertink: ar kitas žmogus galėtų pakartoti tavo veiksmus? Ar aišku, ką reiškia sėkmė? Ar pažymėjai neatliktus bandymus? Tai svarbiau nei gražiai nuspalvinta lentelė.
90 dienų mokymosi planas
Tai redakcinis praktikos planas, ne pažadas per tris mėnesius gauti darbą. Trukmę keisk pagal turimas žinias ir laiką.
| Laikas | Dėmesys | Rezultatas |
|---|---|---|
| 1–30 dienos | Reikalavimai, testų atvejai, ribos, defektų aprašymas | Vienas rankinio testavimo mini projektas |
| 31–60 dienos | HTTP, API, naršyklės diagnostika, duomenys | Papildytas portfolio su techniniais įrodymais |
| 61–90 dienos | Viena automatizavimo priemonė, CV ir pokalbiai | Keli savarankiškai paaiškinami testai ir tikslinės kandidatūros |
Kas savaitę vieną rezultatą parodyk kitam žmogui. Paprašyk konkretaus grįžtamojo ryšio: kur neaiškus tikėtinas rezultatas, kur trūksta sąlygos ir kas dubliuojasi. Pažangą matuok savarankiškai atliktomis užduotimis, o ne vien peržiūrėtų kursų valandomis.
Ar verta laikyti ISTQB ir pirkti kursą?
ISTQB CTFL gali padėti susisteminti terminus ir pagrindus. Oficialus sertifikavimo puslapis pristato jį kaip pagrindinių testavimo žinių kvalifikaciją. Sertifikatas nepakeičia praktinio projekto ir negarantuoja darbo.[7]
Prieš mokėdamas už kursą, palygink jo programą su pasirinktais darbo skelbimais. Patikrink, kiek gausi savarankiškų užduočių, ar kas nors peržiūrės klaidų aprašus ir ar mokoma paaiškinti sprendimus. Atsargiai vertink „garantuoto darbo“ pažadus be aiškių sąlygų. Pirmą mini projektą galima atlikti naudojant viešą dokumentaciją.
Kur ieškoti pirmo darbo ir ką rašyti CV?
Paieškoje derink lietuviškus ir angliškus pavadinimus: „jaunesnysis testuotojas“, „QA praktikantas“, „Junior QA“, „Manual Tester“, „QA Analyst“. Peržiūrėk įmonės karjeros puslapį ir patikrink, ar skelbimas tebėra aktyvus. „Remote“ gali reikšti darbą tik konkrečioje šalyje arba laiko juostoje.
- CV pradžioje nurodyk ieškomą kryptį ir vieną portfolio nuorodą.
- Aprašyk, ką iš tikrųjų testavai, kokius atvejus numatei ir ką dokumentavai.
- Įrankio žinias pagrįsk užduotimi, o ne vien logotipu.
- Aiškiai atskirk mokomąjį projektą nuo apmokamos patirties.
- Pateik anglų kalbos lygį pagal realius gebėjimus skaityti, rašyti ir kalbėti.
Pokalbyje gali tekti paaiškinti, kaip tikrintum prisijungimą ar prekių krepšelį. Pirmiausia klausk apie taisykles, tada siūlyk atvejus. Gebėjimas pastebėti trūkstamą reikalavimą gali būti vertingesnis už ilgą atsitiktinių testų sąrašą.
Kaip atrodo testuotojo darbas iš namų?
Nuotoliu svarbūs stabilus ryšys, prieiga prie bandomosios aplinkos ir aiškus susitarimas, kada esi pasiekiamas. Komandinis testavimas nėra visiškai individualus darbas: reikia aptarti reikalavimus, reprodukuoti kolegos rastą problemą ir perduoti rezultatus.
Prieš priimdamas pasiūlymą išsiaiškink darbo šalį, privalomas bendras valandas, įrangos suteikimą, bandomųjų įrenginių poreikį ir naujoko mokymą. Paklausk, kas peržiūrės tavo testus ir kaip bus matuojama pažanga. Vien pažymėjimas „nuotolinis“ neatsako į šiuos klausimus.
Atlyginimas ir savarankiško darbo kainodara
Vieno patikimo skaičiaus visiems testuotojams nėra: skiriasi patirtis, automatizavimo atsakomybė, produktas ir darbo forma. Šiame gide nepateikiame nepatikrinto Lietuvos atlygio intervalo. Lygindamas aktualius pasiūlymus pasižymėk datą, bruto ar neto sumą, valandas ir reikalavimus.
Savarankiško projekto kainą siek su aiškia apimtimi: kokie vartotojo keliai, kiek aplinkų, kiek laiko tyrimui ir ar įskaičiuota pataisymų patikra. Pavyzdžiui, penki pagrindiniai scenarijai vienoje naršyklėje yra kita paslauga nei visas elektroninės parduotuvės kokybės įvertinimas. Sutark, kokią ataskaitą klientas gaus ir kas laikoma papildomu darbu.
Kaip naudoti DI ir kur juo nepasikliauti?
DI gali pasiūlyti testų idėjų, padėti suformuluoti aiškesnį klaidos aprašymą arba paaiškinti nesuprantamą kodo fragmentą. Kiekvieną pasiūlymą tikrink pagal tikrą reikalavimą. Sugeneruotas testas gali tikrinti neteisingą dalyką ir vis tiek sėkmingai praeiti.
- Nesiųsk klientų duomenų ar prieigos raktų į nepatvirtintą įrankį.
- Naudok išgalvotus pavyzdžius ir minimalią būtiną informaciją.
- Patikrink, ar testas iš tiesų aptinka sąmoningai įvestą gedimą mokomojoje aplinkoje.
- Galutinėje ataskaitoje atskirk įvykdytą bandymą nuo nepatikrintos idėjos.
Karjeros pradžioje svarbiausia mokėti paaiškinti savo sprendimą. DI sukurtas portfolio be supratimo greitai atsiskleidžia, kai pokalbyje paprašo pakeisti vieną sąlygą.
Koks pirmas žingsnis šiandien?
Atsisiųsk praktinę užduotį, paruošk penkis patikrinimus ir vieną aiškų klausimą apie reikalavimus. Jei procesas patiko, užbaik visą mini projektą ir tik tada spręsk dėl ilgesnio kurso. Jei labiau patinka spręsti vartotojo bėdą pokalbio metu, palygink techninę pagalbą; jei kurti funkcijas – svetainių kūrimą.
Techninės pagalbos specialistas ↗ · Svetainių kūrėjas ↗ · Duomenų analitikas ↗
Dažniausiai užduodami klausimai
Ar galima tapti testuotoju be IT diplomo?
Galima mokytis ir kurti portfolio savarankiškai, tačiau kiekvienas darbdavys nustato savo reikalavimus. Pademonstruok testavimo mąstymą ir techninius pagrindus; diplomo nebuvimo nekompensuoja vien kurso pažymėjimas.
Ar testuotojas turi mokėti programuoti?
Rankinio testavimo pradžioje galima susitelkti į scenarijus ir dokumentavimą. Automatizuotų testų kūrimui reikia programavimo, o HTTP ir duomenų supratimas naudingas abiem kryptims.
Ar QA ir testuotojas yra tas pats?
Skelbimuose pavadinimai dažnai persidengia. Kokybės užtikrinimas apima ir procesų gerinimą, o testavimas – konkretaus produkto tikrinimą. Vertink pareigybės užduotis.
Kiek laiko reikia išmokti?
Vieno termino nėra. 90 dienų planas padeda nuosekliai sukurti pirmus darbus, tačiau pasirengimas atrankai priklauso nuo pradinių žinių ir praktikos kokybės.
Ar būtinas ISTQB sertifikatas?
Ne visoms pozicijoms. Jis gali padėti pagrįsti teorines žinias, tačiau praktinių užduočių ir gebėjimo paaiškinti sprendimus nepakeičia.
Ar galima dirbti iš Lietuvos užsienio įmonei?
Tai priklauso nuo įmonės darbo šalių, sutarties ir pasiekiamumo reikalavimų. Skelbimo žyma remote savaime nereiškia, kad priimami kandidatai iš visų šalių.
Ką daryti, jei mokomajame projekte neradau klaidų?
Pateik atliktus patikrinimus ir jų rezultatus. Neprikurk defektų dėl portfolio. Gali aprašyti neaiškų reikalavimą arba nepatikrintą riziką.
Ar reikia galingo kompiuterio?
Paprastiems naršyklės ir dokumentavimo darbams poreikiai mažesni negu kelioms virtualioms aplinkoms ar dideliam lygiagrečiam testų rinkiniui. Tikrink pasirinkto įrankio reikalavimus ir darbdavio suteikiamą įrangą.
Ar testavimas reiškia darbą vienam?
Ne. Net dirbant iš namų reikia aiškintis reikalavimus, perduoti problemas ir aptarti rizikas. Rašytinis bendravimas yra pagrindinis įgūdis.
Ar automatizavimas pakeičia rankinį testavimą?
Automatiniai patikrinimai naudingi pasikartojantiems scenarijams. Naujų rizikų tyrimas, neaiškių reikalavimų aptarimas ir rezultatų interpretavimas lieka svarbūs.
Ar galima testuoti bet kurią viešą svetainę?
Viešas pasiekiamumas nėra leidimas aktyviems saugumo ar apkrovos bandymams. Praktikuokis savo, mokomojoje arba aiškiai sutartoje aplinkoje.
Koks geriausias pirmas portfolio darbas?
Nedidelio vartotojo kelio testavimo planas su tikėtinais ir faktiniais rezultatais, bent vienu aiškiu pastebėjimu ir sąžiningai nurodytomis ribomis.
Šaltiniai ir rengimo principai
Informacija tikrinta 2026 m. rugsėjo 27 d. Praktikos planas, dienos pavyzdys ir užduotis yra redakciniai mokymosi pasiūlymai. JAV profesijos aprašas nenaudojamas Lietuvos atlygiui nustatyti. Įrankių dokumentacija gali keistis.