Ang Pangunahing Problema ng Pagsubok

Pagpapakilala

Magandang hapon, mga residente ng Khabrovsk. Ngayon lang ako nag-solve ng test task para sa isang QA Lead vacancy para sa isang fintech company. Ang unang gawain, upang lumikha ng isang plano sa pagsubok na may kumpletong checklist at mga halimbawa ng mga kaso ng pagsubok para sa pagsubok ng isang electric kettle, ay maaaring malutas nang walang kabuluhan:

• GOST 7400-81. Mga electric kettle at electric samovar. Mga Detalye (na may mga Susog Blg. 1-8)
• GOST IEC 60335-1-2015 Mga sambahayan at katulad na mga de-koryenteng kasangkapan. Kaligtasan. Bahagi 1. Pangkalahatang mga kinakailangan
  Mahirap mag-isip ng mas magandang plano sa pagsubok na may kumpletong checklist.

Ngunit ang pangalawang bahagi ay naging isang tanong: "Mayroon bang anumang mga problema na karaniwan sa lahat ng mga tester na pumipigil sa kanila na gumana nang mas mahusay?"

Ang unang bagay na pumasok sa isip ay ang ilista ang lahat ng mas marami o hindi gaanong kapansin-pansing mga problema na naranasan ko sa pagsubok, alisin ang maliliit na bagay, at ibuod ang iba. Ngunit mabilis kong napagtanto na ang inductive na paraan ay sasagutin ang isang tanong na hindi nalalapat sa "lahat", ngunit, sa pinakamaganda, sa "karamihan" lamang ng mga tester. Samakatuwid, nagpasya akong lapitan ito mula sa kabilang panig, nang deduktibo, at ito ang nangyari.

Mga kahulugan

Ang unang bagay na karaniwan kong ginagawa kapag nilulutas ang isang bagong problema ay ang subukang unawain kung ano ang lahat ng ito, at para magawa ito kailangan kong maunawaan ang kahulugan ng mga salitang nagpapahiwatig nito. Ang mga pangunahing salita na dapat maunawaan ay ang mga sumusunod:

• problema
• tester
• trabaho ng tester
• kahusayan ng tester

Bumaling tayo sa Wikipedia at sentido komun:
Problema (sinaunang Griyego πρόβλημα) sa isang malawak na kahulugan - isang kumplikadong teoretikal o praktikal na isyu na nangangailangan ng pag-aaral at paglutas; sa agham - isang magkasalungat na sitwasyon na lumilitaw sa anyo ng mga magkasalungat na posisyon sa pagpapaliwanag ng anumang mga phenomena, bagay, proseso at nangangailangan ng isang sapat na teorya upang malutas ito; sa buhay, ang problema ay nabuo sa isang anyo na naiintindihan ng mga tao: "Alam ko kung ano, hindi ko alam kung paano," iyon ay, alam kung ano ang kailangang makuha, ngunit hindi alam kung paano ito gagawin. . Galing sa huli. lat. problema, mula sa Greek. πρόβλημα "itinapon pasulong, inilagay sa harap"; mula sa προβάλλω “ihagis pasulong, ilagay sa harap mo; sisihin".

Ito ay hindi gaanong makatuwiran, sa katunayan, "problema" = "anumang bagay na kailangang harapin."
Tester - isang espesyalista (hindi namin hahatiin sa mga uri, dahil interesado kami sa lahat ng mga tester) na nakikibahagi sa pagsubok ng isang bahagi o system, ang resulta nito ay:
Gawain ng tester — isang hanay ng mga aktibidad na nauugnay sa pagsubok.
Kahusayan (lat. effectivus) - ang ugnayan sa pagitan ng nakamit na resulta at mga mapagkukunang ginamit (ISO 9000: 2015).
Resulta - isang kinahinatnan ng isang chain (serye) ng mga aksyon (resulta) o mga kaganapan, na ipinahayag sa qualitatively o quantitatively. Kabilang sa mga posibleng resulta ang kalamangan, kawalan, pakinabang, pagkawala, halaga, at tagumpay.
Tulad ng "problema," mayroong maliit na kahulugan: isang bagay na lumabas bilang resulta ng trabaho.
mapagkukunan - ang quantitatively na masusukat na posibilidad ng pagsasagawa ng anumang aktibidad ng isang tao o mga tao; mga kondisyon na ginagawang posible upang makuha ang nais na resulta gamit ang ilang mga pagbabago. Ang tester ay isang tao, at alinsunod sa teorya ng mahahalagang mapagkukunan, ang bawat tao ay may-ari ng apat na pang-ekonomiyang asset:
cash (kita) ay isang nababagong mapagkukunan;
enerhiya (life force) ay isang bahagyang nababagong mapagkukunan;
ang oras ay isang nakapirming at pangunahing hindi nababagong mapagkukunan;
ang kaalaman (impormasyon) ay isang renewable resource, ito ay bahagi ng human capital na maaaring lumago at masira[1].

Gusto kong tandaan na ang kahulugan ng kahusayan sa aming kaso ay hindi ganap na tama, dahil mas maraming kaalaman ang ginagamit namin, mas mababa ang kahusayan. Samakatuwid, muling tutukuyin ko ang kahusayan bilang "ang ratio sa pagitan ng mga resultang natamo at mga mapagkukunang ginastos." Kung gayon ang lahat ay tama: ang kaalaman ay hindi nasasayang sa panahon ng trabaho, ngunit binabawasan nito ang mga gastos ng tanging hindi nababagong mapagkukunan ng tester - ang kanyang oras.

desisyon

Kaya, naghahanap kami ng mga pandaigdigang problema ng mga tester na nakakapinsala sa pagiging epektibo ng kanilang trabaho.
Ang pinakamahalagang mapagkukunan na ginugol sa trabaho ng isang tester ay ang kanyang oras (ang natitira ay maaaring bawasan dito sa isang paraan o iba pa), at upang mapag-usapan natin ang tamang pagkalkula ng kahusayan, ang resulta ay dapat ding bawasan sa oras. .
Upang gawin ito, isaalang-alang ang isang sistema na ang posibilidad na mabuhay ay tinitiyak ng tester sa pamamagitan ng kanyang trabaho. Ang ganitong sistema ay isang proyekto na may kasamang tester ang koponan. Ang ikot ng buhay ng proyekto ay maaaring halos kinakatawan ng sumusunod na algorithm:

1. Paggawa gamit ang Mga Kinakailangan
2. Pagbuo ng mga teknikal na pagtutukoy
3. Development
4. Pagsubok
5. Ilabas sa produksyon
6. Suporta (goto item 1)

Sa kasong ito, ang buong proyekto ay maaaring recursively nahahati sa mga subproject (mga tampok), na may parehong ikot ng buhay.
Mula sa punto ng view ng proyekto, mas kaunting oras na ginugol dito, mas epektibo ang pagpapatupad nito.
Kaya, dumating kami sa kahulugan ng pinakamataas na posibleng kahusayan ng isang tester mula sa punto ng view ng proyekto - ito ang estado ng proyekto kapag ang oras para sa pagsubok ay zero. Ang isang karaniwang problema para sa lahat ng mga tester ay ang kawalan ng kakayahan upang makamit ang oras na ito.

Paano haharapin ito?

Ang mga konklusyon ay medyo halata at ginamit ng marami sa loob ng mahabang panahon:

1. Ang pag-unlad at pagsubok ay dapat magsimula at magtatapos nang halos sabay-sabay (karaniwang ginagawa ito ng departamento QA). Ang perpektong opsyon ay kapag ang lahat ng functionality na binuo ay sakop na ng mga autotest sa oras na ito ay handa na, na nakaayos sa regression (at, kung maaari, pre-commit) na pagsubok gamit ang ilang uri ng CI.
2. Kung mas maraming feature ang isang proyekto (mas kumplikado ito), mas maraming oras ang kailangang igugol sa pag-check na hindi masira ng bagong functionality ang luma. Samakatuwid, kung mas kumplikado ang proyekto, mas kailangan ang automation pagsubok ng regression.
3. Sa bawat oras na makaligtaan namin ang isang bug sa produksyon at mahahanap ito ng isang user, kailangan naming gumugol ng karagdagang oras sa pagdaan sa ikot ng buhay ng proyekto simula sa punto 1 (Paggawa gamit ang mga kinakailangan, sa kasong ito, mga user). Dahil ang mga dahilan para sa pagkawala ng isang bug ay karaniwang hindi alam, natitira lamang sa amin ang isang optimization path - ang bawat bug na makikita ng mga user ay dapat isama sa regression testing upang matiyak na hindi na ito lilitaw muli.

Pinagmulan: www.habr.com