Pamatproblēma testēšanā

Ievads

Sveiki, Habrā, nesen risināju testu uzdevumu vakancei QA Lead vienā fintech uzņēmumā. Pirmais uzdevums, izveidot testēšanas plānu ar pilnu pārbaudes sarakstu un piemēriem testa gadījumiem elektriskā tējas kanna pārbaudei, tiek atrisināts vienkārši:

• GOST 7400-81. Elektriskās tējas kannas un elektriskie katli mājsaimniecībām. Tehniskās prasības (ar izmaiņām N 1-8)
• GOST IEC 60335-1-2015 Mājsaimniecības un līdzīgi elektriskie aparāti. Drošība. 1. daļa. Vispārējās prasības
  Grūti izdomāt labāku testēšanas plānu ar pilnu pārbaudes sarakstu.

Taču otrā daļa izrādījās jautājums: “Vai pastāv kādas problēmas, kas ir kopīgas visiem testētājiem un traucē strādāt efektīvāk?”.

Pirmais, kas nāca prātā: uzskaitīt visas kaut cik redzamās problēmas, ar kurām esmu saskāries testēšanas procesā, izslēgt niekus un pārējo apvienot. Taču ātri sapratu, ka induktīvais metode atbildēs uz jautājumu, kas attiecas ne uz “visi”, bet labākajā gadījumā tikai uz “lielāko daļu” testētāju. Tāpēc nolēmu pieiet no citas puses, deduktīvās, un lūk, ko es ieguvu.

Definīcijas

Pirmais, ko parasti daru, risinot jaunu uzdevumu, ir centies saprast, par ko tas patiešām ir, un tam ir jāsaprot vārdu jēga, ar kuriem tas izvirzīts. Atslēgvārdi, kuriem jāpievērš uzmanība, ir sekojoši:

• problēma
• testētājs
• testētāja darbs
• testētāja darba efektivitāte

Pievēršamies Vikipēdijai un saprātam:
Problēma (sen-grieķu πρόβλημα) plašā nozīmē — sarežģīts teorētiķis vai praktisks jautājums, kas prasa izpēti, risinājumu; zinātnē — pretrunīga situācija, kas parādās pretrunīgu pozīciju veidā kādā parādību, objektu, procesu skaidrojumā un prasa adekvātu teoriju tās risināšanai; dzīvē problēma tiek formulēta saprotamā cilvēkiem veidā “zinu, kas, nezinu, kā”, t.i., ir zināms, ka ir nepiecieams sasniegt, bet nav zināms, kā to izdarīt. Tas nāk no vēlā latīņu problēma, no grieķu πρόβλημα “mest uz priekšu, izvirzīt priekšā”; no προβάλλω “mest uz priekšu, izvirzīt priekšā; apsūdzēt.”

Jēgas nav daudz, būtībā “problēma” = “jebkas, ar ko jāstrādā”.
Testētājs — speciālists (nesadalot pa veidiem, jo mūs interesē visi testētāji), kurš piedalās komponentes vai sistēmas testēšanā, kura darbības rezultāts ir:
Testētāja darbs — pasākumu komplekss, kas attiecas uz testēšanu.
Efektivitāte (lat. effectivus) — attiecība starp sasniegto rezultātu un izmantotajiem resursiem (ISO 9000:2015).
Rezultāts — seku ķēde (sērijas) darbībām (rezultāts) vai notikumiem, kas tiek izteikti kvalitatīvi vai kvantitatīvi. Iespējamie rezultāti ietver priekšrocību, neērtību, ieguvumu, zaudējumu, vērtību un uzvaru.
Kā ar "problēmu", nozīme ir maz: kaut kas, kas iznāca beigās.
Resursa — kvantitatīvi izmērāma iespēja veikt kādu cilvēka vai cilvēku darbību; nosacījumi, kas ļauj ar noteiktiem pārveidojumiem sasniegt vēlamo rezultātu. Testētājs — cilvēks, un saskaņā ar vitālo resursu teoriju katram cilvēkam ir četri ekonomiskie aktīvi:
naudas līdzekļi (ienākumi) — resurss, kas ir atjaunojams;
enerģija (dzīvotspēja) — resurss, kas ir daļēji atjaunojams;
laiks — resurss, kas ir fiksēts un principā nav atjaunojams;
zināšanas (informācija) — resurss, kas ir atjaunojams, daļa no cilvēku kapitāla, kas var gan pieaugt, gan sabrukt.[1].

Vēlos atzīmēt, ka šī definīcija efektivitātei mūsu gadījumā nav pavisam pareiza, jo jo vairāk zināšanu mēs izmantojam, jo zemāka ir efektivitāte. Tādēļ es pārdefinētu efektivitāti kā “attiecību starp sasniegto rezultātu un patērētajiem resursiem”. Tad viss ir pareizi: zināšanas darbā netiek iztērētas, bet samazina vienīgo principā nenovērtējamo testētāja resursu — viņa laiku.

Risinājums

Tātad meklējam globālās problēmas testētājiem, kas pasliktina viņu darba efektivitāti.
Visnozīmīgākais resurss, ko testētājs tērē darbā, ir viņa laiks (pārējos kaut kā var attiecināt uz to), un, lai mēs varētu runāt par pareizu efektivitātes aprēķinu, ir jāizsaka arī rezultāts laikā.
Lai to izdarītu, apskatīsim sistēmu, kuras dzīvotspēju testētājs nodrošina ar savu darbu. Šāda sistēma ir projekts, kura komandā ietilpst testētājs. Projekta dzīves ciklu var aptuveni attēlot šādā algoritmā:

1. Darbs ar prasībām
2. Tehniskā uzdevuma izstrāde
3. Izstrāde
4. Testēšana
5. Ražošanas izlaišana
6. Atbalsts (pāreja uz p.1)

Šajā gadījumā visu projektu var rekurīvi sadalīt apakšprojektos (funkcijās), ar tādiem pašiem dzīves cikliem.
No projekta skatpunkta, tā īstenošanas efektivitāte ir lielāka, jo mazāk laika tam tiek tērēts.
Tādējādi mēs nonākam pie definīcijas par maksimāli iespējamo testētāja efektivitāti no projekta skatpunkta — tas ir projekts, kurā laiks testēšanai ir vienāds ar nulli. Un kopējā problēma visiem testētājiem ir šī laika sasniegšana.

Ko ar to darīt?

Secinājumi ir pavisam acīmredzami un jau daudzus gadus tiek izmantoti:

1. Izstrāde un testēšana jāsāk un jāpabeidz praktiski vienlaikus (parasti ar to nodarbojas QA). Ideāls variants ir tad, kad visa izstrādātā funkcionalitāte brīdī, kad tā ir gatava, jau ir segta ar automatizētiem testiem, kas organizēti regresijas (un, cik iespējams, arī priekš-komitējuma) testēšanā ar kādu no CI.
2. Jo vairāk projektā ir funkciju (jo tas ir sarežģītāks), jo vairāk laika būs jātērē, lai pārliecinātos, ka jaunā funkcionalitāte nesabojāja veco. Tāpēc, jo sarežģītāks ir projekts, jo vairāk automatizācijas nepieciešams regresijas testēšanai.
3. Katrreiz, kad mēs izlaižam kļūdu ražošanā, un lietotājs to atklāj — mums nākas tērēt papildu laiku, lai izietu cauri projekta dzīves ciklam, sākot no p.1 (Darbs ar prasībām, šajā gadījumā - lietotāju prasībām). Tā kā kļūdu izlaišanas iemesli vispārīgi ir nezināmi, mums atliek tikai viena optimizācijas ceļa — katrai, ko lietotāji atklājuši, kļūdai jāiekļaujas regresijas testēšanā, lai būtu pārliecināti, ka tā vairs neparādīsies.

Avots: habr.com