Labdien, Habrovskas iedzÄ«votÄji. Nupat es risinu testa uzdevumu QA Lead vakancei fintech uzÅÄmumÄ. Pirmo uzdevumu, izveidot testa plÄnu ar pilnu kontrolsarakstu un elektriskÄs tÄjkannas testÄÅ”anas testÄÅ”anas gadÄ«jumu piemÄriem, var atrisinÄt triviÄli:
Bet otrÄ daļa izrÄdÄ«jÄs jautÄjums: "Vai visiem testÄtÄjiem ir kopÄ«gas problÄmas, kas neļauj viÅiem strÄdÄt efektÄ«vÄk?"
Pirmais, kas ienÄca prÄtÄ, bija uzskaitÄ«t visas vairÄk vai mazÄk pamanÄmÄs problÄmas, ar kurÄm saskÄros testÄÅ”anas laikÄ, atsijÄt sÄ«kumus un apkopot pÄrÄjo. Bet es Ätri sapratu, ka induktÄ«vÄ metode atbildÄs uz jautÄjumu, kas neattiecas uz "visiem", bet labÄkajÄ gadÄ«jumÄ tikai uz "lielÄko daļu" testÄtÄju. TÄpÄc nolÄmu tam pieiet no otras puses, deduktÄ«vi, un tÄ arÄ« notika.
definÄt
PirmÄ lieta, ko parasti daru, risinot jaunu problÄmu, ir mÄÄ£inÄt saprast, par ko tÄ ir, un, lai to izdarÄ«tu, man ir jÄsaprot to vÄrdu nozÄ«me, kas to rada. AtslÄgas vÄrdi, kas jÄsaprot, ir Å”Ädi:
problÄma
testeris
testÄtÄja darbs
testera efektivitÄte
PievÄrsÄ«simies VikipÄdijai un veselajam saprÄtam: ProblÄma (sengrieÄ·u ĻĻĻĪ²Ī»Ī·Ī¼Ī±) plaÅ”Ä nozÄ«mÄ - sarežģīts teorÄtisks vai praktisks jautÄjums, kas prasa izpÄti un risinÄjumu; zinÄtnÄ - pretrunÄ«ga situÄcija, kas parÄdÄs pretÄju pozÄ«ciju veidÄ jebkuru parÄdÄ«bu, objektu, procesu skaidrojumÄ un prasa adekvÄtu teoriju tÄs atrisinÄÅ”anai; dzÄ«vÄ problÄma tiek formulÄta cilvÄkiem saprotamÄ formÄ: āEs zinu, kas, es nezinu kÄā, tas ir, ir zinÄms, kas jÄiegÅ«st, bet nav zinÄms, kÄ to izdarÄ«t. . NÄk no vÄlu. latu. problÄma no grieÄ·u valodas. ĻĻĻĪ²Ī»Ī·Ī¼Ī± āizmests uz priekÅ”u, novietots priekÅ”Äā; no ĻĻĪæĪ²Ī¬Ī»Ī»Ļ āmest uz priekÅ”u, nolikt sev priekÅ”Ä; vainot".
Tam nav lielas jÄgas, patiesÄ«bÄ āproblÄmaā = āviss, kas jÄrisinaā. TestÄtÄjs - speciÄlists (nedalÄ«sim tipos, jo mÅ«s interesÄ visi testÄtÄji), kurÅ” piedalÄs komponenta vai sistÄmas testÄÅ”anÄ, kuras rezultÄts ir: TestÄtÄja darbs ā ar testÄÅ”anu saistÄ«tu darbÄ«bu kopums. EfektivitÄte (lat. Effectivus) - attiecÄ«ba starp sasniegto rezultÄtu un izmantotajiem resursiem (ISO 9000: 2015). RezultÄts - darbÄ«bu (rezultÄta) vai notikumu Ä·Ädes (sÄrijas) sekas, kas izteiktas kvalitatÄ«vi vai kvantitatÄ«vi. IespÄjamie rezultÄti ietver priekÅ”rocÄ«bas, trÅ«kumus, ieguvumus, zaudÄjumus, vÄrtÄ«bu un uzvaru.
TÄpat kÄ āproblÄmaiā, tam ir maz nozÄ«mes: kaut kas tÄds, kas radÄs darba rezultÄtÄ. resursi - kvantitatÄ«vi izmÄrÄma iespÄja veikt kÄdu personas vai cilvÄku darbÄ«bu; apstÄkļi, kas ļauj izmantot noteiktas transformÄcijas, lai iegÅ«tu vÄlamo rezultÄtu. TestÄtÄjs ir persona, un saskaÅÄ ar vitÄlo resursu teoriju katra persona ir Äetru saimniecisko aktÄ«vu Ä«paÅ”nieks:
nauda (ienÄkumi) ir atjaunojams resurss;
enerÄ£ija (dzÄ«vÄ«bas spÄks) ir daļÄji atjaunojams resurss;
laiks ir nemainÄ«gs un bÅ«tÄ«bÄ neatjaunojams resurss;
zinÄÅ”anas (informÄcija) ir atjaunojams resurss, tÄ ir daļa no cilvÄkkapitÄla, kas var augt un tikt iznÄ«cinÄts[1].
Es vÄlos atzÄ«mÄt, ka efektivitÄtes definÄ«cija mÅ«su gadÄ«jumÄ nav pilnÄ«gi pareiza, jo, jo vairÄk zinÄÅ”anu mÄs izmantojam, jo āāzemÄka ir efektivitÄte. TÄpÄc es no jauna definÄtu efektivitÄti kÄ "attiecÄ«bu starp sasniegtajiem rezultÄtiem un iztÄrÄtajiem resursiem". Tad viss ir pareizi: zinÄÅ”anas darba laikÄ netiek izniekotas, bet tas samazina testÄtÄja vienÄ«gÄ principiÄli neatjaunojamÄ resursa - viÅa laika - izmaksas.
Å Ä·Ä«dums
TÄtad, mÄs meklÄjam globÄlas testÄtÄju problÄmas, kas mazina viÅu darba efektivitÄti.
NozÄ«mÄ«gÄkais resurss, kas tiek tÄrÄts testÄtÄja darbam, ir viÅa laiks (pÄrÄjais tÄ vai tÄ var tikt samazinÄts lÄ«dz tam), un, lai mÄs varÄtu runÄt par pareizu efektivitÄtes aprÄÄ·inu, arÄ« rezultÄts ir jÄreducÄ uz laiku .
Lai to izdarÄ«tu, apsveriet sistÄmu, kuras dzÄ«votspÄju testÄtÄjs nodroÅ”ina ar savu darbu. Å Äda sistÄma ir projekts, kura komandÄ ir testÄtÄjs. Projekta dzÄ«ves ciklu var aptuveni attÄlot ar Å”Ädu algoritmu:
Darbs ar prasÄ«bÄm
Tehnisko specifikÄciju veidoÅ”ana
Attīstība
TestÄÅ”ana
Izlaist ražoÅ”anÄ
Atbalsts (pÄriet uz 1. vienumu)
Å ajÄ gadÄ«jumÄ visu projektu var rekursÄ«vi sadalÄ«t apakÅ”projektos (funkcijÄs) ar vienÄdu dzÄ«ves ciklu.
No projekta viedokļa, jo mazÄk laika tiek veltÄ«ts tam, jo āāefektÄ«vÄka ir tÄ Ä«stenoÅ”ana.
TÄdÄjÄdi mÄs nonÄkam pie testera maksimÄli iespÄjamÄs efektivitÄtes definÄ«cijas no projekta viedokļa - tas ir projekta stÄvoklis, kad testÄÅ”anas laiks ir nulle. Visu testÄtÄju izplatÄ«ta problÄma ir nespÄja sasniegt Å”o laiku.
KÄ ar to tikt galÄ?
SecinÄjumi ir diezgan acÄ«mredzami, un daudzi tos izmantojuÅ”i jau ilgu laiku:
IzstrÄdei un testÄÅ”anai jÄsÄkas un jÄbeidzas gandrÄ«z vienlaikus (to parasti veic nodaļa QA). IdeÄls variants ir tad, kad visas izstrÄdÄtÄs funkcionalitÄtes jau tiek veiktas ar automÄtiskajiem testiem, kad tÄ ir gatava, un tiek organizÄta regresijas (un, ja iespÄjams, iepriekÅ”Äjas) testÄÅ”anÄ, izmantojot kÄdu CI.
Jo vairÄk iespÄju ir projektam (jo tas ir sarežģītÄks), jo vairÄk laika bÅ«s jÄpavada, lai pÄrbaudÄ«tu, vai jaunÄ funkcionalitÄte nesalauž veco. TÄdÄjÄdi, jo sarežģītÄks projekts, jo lielÄka ir nepiecieÅ”ama automatizÄcija regresijas pÄrbaude.
Katru reizi, kad mÄs palaižam garÄm kļūdu ražoÅ”anÄ un lietotÄjs to atrod, mums ir jÄpavada papildu laiks, izejot cauri projekta dzÄ«ves ciklam, sÄkot no 1. punkta (Darbs ar prasÄ«bÄm, Å”ajÄ gadÄ«jumÄ lietotÄjiem). TÄ kÄ kļūdas izlaiÅ”anas iemesli parasti nav zinÄmi, mums atliek tikai viens optimizÄcijas ceļŔ ā katra lietotÄju atrastÄ kļūda ir jÄiekļauj regresijas pÄrbaudÄ, lai pÄrliecinÄtos, ka tÄ vairs neparÄdÄ«sies.