TestÄ“Å”anas pamatproblēma

Ievads

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:

  1. Darbs ar prasībām
  2. Tehnisko specifikāciju veidoŔana
  3. Attīstība
  4. TestēŔana
  5. Izlaist ražoŔanā
  6. 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:

  1. 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.
  2. 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.
  3. 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.

Avots: www.habr.com

Pievieno komentāru