Pagpapakilala
Kumusta, mga gumagamit ng Habr. Nakumpleto ko kamakailan ang isang takdang-aralin sa pagsusulit para sa isang posisyon sa QA Lead sa isang kumpanya ng fintech. Ang unang gawain, ang paglikha 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 hindi mahalaga upang malutas:
Mahirap makabuo ng mas magandang plano sa pagsubok na may kumpletong checklist.
Ang pangalawang bahagi, gayunpaman, ay naging isang tanong: "Mayroon bang anumang mga problema na karaniwan sa lahat ng mga tester na pumipigil sa kanila na gumana nang mas epektibo?"
Ang unang bagay na pumasok sa isip ay ang ilista ang lahat ng mas marami o hindi gaanong kapansin-pansing mga problema na nakatagpo ko sa panahon ng pagsubok, alisin ang mga walang halaga, at gawing pangkalahatan ang iba. Ngunit mabilis kong napagtanto na ang pamamaraang induktibo ay sasagutin ang isang tanong na hindi naaangkop sa "lahat" ngunit, sa pinakamaganda, sa "karamihan" na mga tagasubok lamang. Kaya't nagpasya akong lapitan ito mula sa ibang, deduktibong anggulo, at ito ang aking naisip.
Mga kahulugan
Ang unang bagay na karaniwan kong ginagawa kapag nilulutas ang isang bagong problema ay subukang unawain kung ano ang lahat ng ito, at para magawa iyon, kailangan kong maunawaan ang kahulugan ng mga salitang ginamit. Ang mga pangunahing salita na dapat maunawaan ay:
- problema
- tester
- trabaho ng tester
- pagganap ng tester
Bumaling tayo sa Wikipedia at sentido komun:
(Sinaunang Griyego: πρόβλημα) sa isang malawak na kahulugan - isang kumplikadong teoretikal o praktikal na tanong 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 ilang mga phenomena, bagay, proseso at nangangailangan ng isang sapat na teorya para sa paglutas nito; sa buhay, ang isang problema ay nabubuo sa paraang naiintindihan ng mga tao, "Alam ko kung ano, hindi ko alam kung paano", ibig sabihin, alam kung ano ang kailangang makamit, ngunit hindi alam kung paano ito gagawin. Nagmula sa Late Latin na problēma, mula sa Greek πρόβλημα "itinapon pasulong, inilagay sa harap"; from προβάλλω "to throw forward, to put in front of oneself; to accuse".
Hindi gaanong makatuwiran, mahalagang "problema" = "anumang bagay na kailangang harapin."
— isang espesyalista (hindi kami mag-iiba sa pagitan ng mga uri, dahil interesado kami sa lahat ng mga tester) na nakikilahok sa pagsubok ng isang bahagi o system, ang resulta ng kung saan ang trabaho ay:
— isang hanay ng mga aktibidad na nauugnay sa pagsubok.
(Latin: effectivus) - ang ratio sa pagitan ng nakamit na resulta at mga mapagkukunang ginamit (: 2015).
— ang kinahinatnan (kinalabasan) ng isang chain (sequence) ng mga aksyon o kaganapan, na ipinahayag nang may husay o dami. Kabilang sa mga posibleng resulta ang kalamangan, kawalan, pakinabang, pagkawala, halaga, at tagumpay.
Tulad ng "problema", mayroong maliit na kahulugan: isang bagay na nagresulta mula sa trabaho.
— isang quantitatively measured na kakayahang magsagawa ng anumang aktibidad ng isang tao o mga tao; mga kondisyon na nagbibigay-daan sa nais na resulta na makamit sa pamamagitan ng ilang mga pagbabago. Ang isang tester ay isang tao, at ayon sa teorya ng mahahalagang mapagkukunan, ang bawat tao ay nagtataglay ng apat na pang-ekonomiyang pag-aari:
cash (kita) ay isang nababagong mapagkukunan;
enerhiya (vital force) ay isang bahagyang nababagong mapagkukunan;
ang oras ay isang nakapirming at pangunahing hindi nababagong mapagkukunan;
ang kaalaman (impormasyon) ay isang nababagong mapagkukunan; ito ay bahagi ng kapital ng tao na parehong maaaring lumago at masira.
Gusto kong ituro na ang kahulugan ng kahusayan sa aming kaso ay hindi ganap na tumpak, dahil mas maraming kaalaman ang ginagamit namin, mas mababa ang kahusayan. Samakatuwid, muli kong tutukuyin ang kahusayan bilang "ang ratio sa pagitan ng nakamit na resulta at mga mapagkukunang ginastos." Kung gayon ang lahat ay tama: ang kaalaman ay hindi nasasayang sa panahon ng trabaho, ngunit binabawasan nito ang paggasta ng tanging pangunahing hindi nababagong mapagkukunan ng tester—ang kanilang oras.
desisyon
Kaya, naghahanap kami ng mga pandaigdigang problema ng mga tester na nagpapababa sa kahusayan ng kanilang trabaho.
Ang pinakamahalagang mapagkukunan na ginugol sa trabaho ng isang tester ay ang kanyang oras (ang iba pang mga mapagkukunan ay maaaring maiugnay dito sa isang paraan o iba pa), at upang pag-usapan ang tungkol sa isang tamang pagkalkula ng kahusayan, ang resulta ay dapat ding nauugnay sa oras.
Upang gawin ito, isaalang-alang natin ang isang sistema na ang posibilidad na mabuhay ay tinitiyak ng trabaho ng tester. Ang ganitong sistema ay isang proyekto na may kasamang tester ang koponan. Ang lifecycle ng proyekto ay maaaring halos kinakatawan ng sumusunod na algorithm:
- Nagtatrabaho sa mga kinakailangan
- Pagbuo ng mga teknikal na pagtutukoy
- Development
- Pagsubok
- Ilabas sa produksyon
- Suporta (goto p.1)
Sa kasong ito, ang buong proyekto ay maaaring recursively nahahati sa mga subproject (mga tampok), na may parehong ikot ng buhay.
Mula sa pananaw ng proyekto, mas kaunting oras na ginugol sa isang proyekto, mas malaki ang bisa nito.
Kaya, nakarating kami sa isang kahulugan ng pinakamataas na posibleng kahusayan ng tester mula sa isang pananaw ng proyekto: ito ang estado ng proyekto kapag ang oras para sa pagsubok ay zero. At ang karaniwang problema para sa lahat ng mga tester ay ang imposibilidad na makamit ang oras na ito.
Paano haharapin ito?
Ang mga konklusyon ay medyo halata at ginamit ng marami sa loob ng mahabang panahon:
- Ang pag-unlad at pagsubok ay dapat magsimula at matapos nang halos sabay-sabay (karaniwang ginagawa ito ng departamento ). Ang perpektong opsyon ay kapag ang lahat ng functionality na binuo ay sakop na ng mga automated na pagsubok sa oras na ito ay handa na, nakaayos sa regression (at, kung maaari, pre-commit) na pagsubok gamit ang ilang uri ng .
- Kung mas maraming feature ang isang proyekto (mas kumplikado ito), mas maraming oras ang kailangang gugulin sa pagsuri na hindi masira ng bagong functionality ang luma. Samakatuwid, kung mas kumplikado ang proyekto, mas kinakailangan ang automation. .
- Sa tuwing hahayaan namin ang isang bug sa produksyon at mahahanap ito ng user, kailangan naming gumugol ng karagdagang oras sa pagdaan sa lifecycle ng proyekto, simula sa hakbang 1 (paggawa gamit ang mga kinakailangan, sa kasong ito, mga kinakailangan ng user). Dahil ang mga dahilan para sa pagtanggal ng isang bug ay karaniwang hindi alam, mayroon lang kaming isang opsyon sa pag-optimize: bawat bug na makikita ng mga user ay dapat isama sa regression testing upang matiyak na hindi ito muling lilitaw.
Pinagmulan: www.habr.com
