Hoy Habr!
Mayroon kaming bagong mahalagang paksa - mataas na kalidad na pag-unlad ng mga produktong IT. Sa HighLoad++ madalas naming pinag-uusapan kung paano pabilisin ang mga abalang serbisyo, at sa Frontend Conf pinag-uusapan namin ang isang cool na user interface na hindi bumabagal. Regular kaming may mga paksa tungkol sa pagsubok, at DevOpsConf tungkol sa pagsasama-sama ng iba't ibang proseso, kabilang ang pagsubok. Ngunit tungkol sa kung ano ang maaaring tawaging kalidad sa pangkalahatan, at kung paano magtrabaho sa komprehensibong paraan - hindi.
Ayusin natin ito sa pamamagitan ng — bubuo kami ng kultura ng pag-iisip tungkol sa kalidad ng panghuling produkto para sa user sa bawat yugto ng pag-unlad. Ang ugali na hindi tumuon sa iyong lugar ng responsibilidad, at pag-uugnay ng kalidad hindi lamang sa mga tester.
Sa ibaba ng hiwa ay makikipag-usap tayo sa pinuno ng komite ng programa, pinuno ng pagsubok sa Tinkoff.Business, tagalikha ng komunidad ng QA na nagsasalita ng Ruso Anastasia Aseeva-Nguyen tungkol sa estado ng industriya ng QA at ang misyon ng bagong kumperensya.
- Nastia hello. Mangyaring sabihin sa amin ang tungkol sa iyong sarili.
Анастасия: Pinamamahalaan ko ang pagsubok sa isang bangko, responsable ako para sa isang napakalaking koponan - kami ay higit sa 90 katao. Mayroon kaming mahalagang linya ng negosyo; responsable kami para sa ecosystem para sa mga legal na entity.
Nag-aral ako ng mechanics at mathematics at sa una ay gusto kong maging programmer. Ngunit nang makakuha ako ng isang kawili-wiling alok, nagpasya akong subukan ang aking sarili bilang isang tester. Kakatwa, ito pala ang tawag ko. Ngayon nakita ko na lahat ng trabaho ko sa industriyang ito.
Ako ay isang masigasig na sumusunod sa disiplina ng Quality Assurance. Hindi ako walang malasakit sa kung anong mga produkto ang nilikha, kung paano tinatrato ang kalidad sa kumpanya, sa koponan at, sa prinsipyo, sa proseso ng pag-unlad.
Obvious naman sa akin yun ang komunidad sa direksyong ito ay hindi sapat na mature, hindi bababa sa Russia. Hindi namin palaging nauunawaan na ang kasiguruhan sa kalidad ay hindi lamang ang katotohanan ng pagsubok sa isang aplikasyon para sa pagsunod sa mga kinakailangan. Gusto kong baguhin ang sitwasyong ito.
— Gumagamit ka ng mga salitang Quality Assurance at pagsubok. Sa mata ng karaniwang tao, ang dalawang terminong ito ay madalas na magkakapatong. Paano sila nagkakaiba kung maghuhukay ka ng malalim?
Anastasia: Sa halip, hindi sila naiiba. Ang pagsubok ay bahagi ng disiplina sa Quality Assurance; ito ay isang direktang aktibidad - ang mismong katotohanan na may sinusubukan ako. Mayroong talagang maraming uri ng pagsubok, at iba't ibang tao ang may pananagutan para sa iba't ibang uri ng pagsubok. Ngunit dito sa Russia, nang lumitaw ang isang alon ng mga outsourcer na nagbibigay ng mga tester sa mga kumpanya, ang pagsubok ay nabawasan sa isang uri.
Sa karamihan ng mga kaso, limitado lang ang mga ito sa functional na pagsubok: tinitingnan nila kung ang na-code ng mga developer ay sumusunod sa detalye at iyon lang.
— Mangyaring sabihin sa amin kung ano ang iba pang mga disiplina sa pagtiyak ng kalidad na naroroon? Ano pa, bukod sa pagsubok, ang kasama dito?
Анастасия: Ang Quality Assurance ay, una sa lahat, tungkol sa paglikha ng isang kalidad na produkto. Ibig sabihin, tinatanong natin ang ating sarili kung anong mga katangian ng kalidad ang dapat magkaroon ng ating produkto. Alinsunod dito, kung mauunawaan natin ito, maihahambing natin kung sino ang nakakaimpluwensya sa mga katangiang ito ng kalidad. Hindi mahalaga, developer, project manager o product specialist ay isang taong nakakaimpluwensya sa pagbuo ng isang produkto, ang backlog nito, at ang diskarte nito.
Mas nababatid ng tester ang kanyang tungkulin. Nauunawaan niya na ang kanyang gawain ay hindi lamang upang subukan ang pagsunod sa mga kinakailangan, kundi pati na rin upang subukan ang mga kinakailangan, tanungin ang mga pormulasyon na nagmumula sa espesyalista ng produkto, at ibunyag ang lahat ng mga implicit na kinakailangan at inaasahan ng kliyente. Kapag naghatid kami ng bagong functionality sa aming customer, dapat talaga naming matugunan ang kanilang mga inaasahan at lutasin ang kanilang sakit. Kung iisipin natin ang lahat ng mga katangian ng kalidad, ang kliyente ay masisiyahan at mauunawaan na ang kumpanya na ang produkto ay ginagamit niya ay talagang nagmamalasakit sa kanyang mga interes, at hindi gumagana sa prinsipyo ng "para lamang maglabas ng isang tampok."
— Mukhang ang inilarawan mo lang ay ang gawain ng isang espesyalista sa produkto. Ito, sa prinsipyo, ay hindi tungkol sa pagsubok at hindi tungkol sa kalidad - ito ay karaniwang tungkol sa pamamahala ng produkto, hindi ba?
Анастасия: Kasama. Ang Quality Assurance ay hindi isang disiplina kung saan may pananagutan ang isang partikular na tao. Ngayon ay mayroong isang popular na direksyon sa pagsubok, isang diskarte na tinatawag Agile Testing. Ang kanyang kahulugan ay malinaw na nagsasaad na ito ay isang diskarte ng koponan sa pagsubok, na kinabibilangan ng isang tiyak na hanay ng mga kasanayan. Ang buong team ay may pananagutan sa pagpapatupad ng diskarteng ito; hindi na kailangan na mayroong tester sa team. Ang buong team ay nakatuon sa paghahatid ng halaga sa customer at pagtiyak na ang halaga ay nakakatugon sa mga inaasahan ng customer.
— Lumalabas na ang kalidad ay sumasalubong sa halos lahat ng nakapalibot na mga disiplina, na nagpapataw ng isang balangkas sa lahat ng bagay sa paligid?
Анастасия: Tama. Kapag iniisip natin kung paano natin gustong lumikha ng isang de-kalidad na produkto, magsisimula tayong mag-isip tungkol sa iba't ibang katangian ng kalidad. Halimbawa, kung paano suriin kung talagang ginawa namin ang tampok na kailangan ng aming kliyente.
Dito pumapasok ang ganitong uri ng pagsubok: UAT (pagsubok sa pagtanggap ng gumagamit). Sa kasamaang palad, ito ay bihirang gawin sa Russia, ngunit kung minsan ay naroroon sa mga koponan ng SCRUM bilang isang demo para sa huling kliyente. Ito ay isang medyo karaniwang uri ng pagsubok sa mga dayuhang kumpanya. Bago buksan ang pag-andar sa lahat ng mga kliyente, ginagawa muna namin ang UAT, iyon ay, inaanyayahan namin ang end user na sumusubok at agad na nagbibigay ng feedback - kung ang produkto ay talagang nakakatugon sa mga inaasahan at malulutas ang sakit. Pagkatapos lamang nito magaganap ang pag-scale sa lahat ng iba pang kliyente.
Iyon ay, nakatuon kami sa negosyo, sa huling kliyente, ngunit sa parehong oras huwag kalimutan ang tungkol sa teknolohiya. Ang kalidad ng produkto ay nakasalalay din sa teknolohiya. Kung mayroon kaming hindi magandang arkitektura, hindi namin mabilis na mailalabas ang mga feature at matutugunan ang mga inaasahan ng customer. Maaaring mayroong maraming mga bug kapag sinusubukang sukatin, o kapag sinusubukang i-refactor maaari tayong masira ang isang bagay. Ang lahat ng ito ay makakaapekto sa kasiyahan ng customer.
Mula sa puntong ito, ang arkitektura ay dapat na tulad na maaari naming magsulat ng malinis na code na magpapahintulot sa amin na mabilis na gumawa ng mga pagbabago at hindi matakot na masira namin ang lahat. Upang ang mga pag-ulit ng rebisyon ay hindi umabot sa loob ng ilang buwan dahil lang sa napakaraming legacy namin, at kailangan naming gumawa ng mahahabang yugto ng pagsubok.
— Sa kabuuan, kasali na ang mga developer, arkitekto, siyentipiko ng produkto, tagapamahala ng produkto, at mga tagasubok mismo. Sino pa ang kasangkot sa proseso ng pagtiyak ng kalidad?
Анастасия: Ngayon isipin natin na naihatid na natin ang feature sa kliyente. Malinaw, ang kalidad ng produkto ay kailangang subaybayan kahit na ito ay nasa produksyon na. Sa yugtong ito, maaaring lumitaw ang mga sitwasyong may mga hindi halatang sitwasyon, ang tinatawag na mga bug.
Ang unang tanong ay paano natin haharapin ang mga bug na ito pagkatapos nating mailabas ang produkto? Paano tayo, halimbawa, tumugon sa stress? Ang kliyente ay hindi magiging napakasaya kung ang pahina ay tumatagal ng higit sa 30 segundo upang mai-load.
Dito pumapasok ang pagsasamantala o, kung tawagin nila ngayon, DevOps. Sa katunayan, ito ang mga taong responsable sa pagpapatakbo ng produkto kapag ito ay nasa produksyon na. Kabilang dito ang iba't ibang uri ng pagsubaybay. Mayroong kahit isang subtype ng pagsubok - pagsubok sa produksyon, kapag pinapayagan namin ang aming sarili na hindi subukan ang isang bagay bago ilunsad at subukan ito kaagad sa produksyon. Ito ay isang serye ng mga hakbang mula sa punto ng view ng pag-aayos ng imprastraktura na nagbibigay-daan sa iyong mabilis na tumugon sa isang insidente, maimpluwensyahan ito, at itama ito.
Mahalaga rin ang imprastraktura. Mayroong madalas na mga sitwasyon kung saan, sa panahon ng pagsubok, imposibleng tiyakin na mayroon talaga tayong lahat ng gusto nating ibigay sa kliyente. Inilalabas namin ito sa produksyon at nagsimulang mahuli ang mga hindi halatang sitwasyon. At lahat dahil ang imprastraktura sa pagsubok ay hindi tumutugma sa imprastraktura sa produksyon. Ito ay humahantong sa isang bagong uri ng pagsubok - pagsubok sa imprastraktura. Ito ay iba't ibang mga pagsasaayos, mga setting, paglilipat ng database, atbp.
Itinaas nito ang tanong - marahil ang koponan ay kailangang gumamit ng imprastraktura bilang code.
Naniniwala ako na ang imprastraktura ay direktang nakakaapekto sa kalidad ng produkto.
Sana may report sa conference na may totoong kaso. Sumulat sa amin kung handa ka nang sabihin sa amin mula sa iyong sariling karanasan kung paano nakakaapekto sa kalidad ang imprastraktura bilang code. Ang imprastraktura bilang code ay ginagawang mas madali upang suriin ang lahat ng mga setting at subukan ang mga bagay na kung hindi man ay hindi posible. Samakatuwid, ang operasyon ay kasangkot din sa proseso ng pagbuo ng isang kalidad na produkto.
— Kumusta naman ang analytics at dokumentasyon?
Анастасия: Mas nalalapat ito sa mga sistema ng enterprise. Kapag pinag-uusapan natin ang tungkol sa negosyo, ang mga tao tulad ng mga analyst at system analyst ay agad na naiisip. Minsan tinatawag silang mga teknikal na manunulat. Nakatanggap sila ng isang gawain upang magsulat ng isang detalye at kumpletuhin ito, halimbawa, para sa isang buwan.
Paulit-ulit na napatunayan na ang pagsusulat ng naturang dokumentasyon ay humahantong sa napakahabang pag-uulit ng pag-unlad at mahabang pag-ulit ng pagpipino, dahil sa panahon ng proseso ng pagsubok ay natukoy ang mga bug at nagsisimula ang mga pagbabalik. Bilang resulta, maraming mga loop na nagpapataas ng mga gastos sa pag-unlad. Bilang karagdagan, maaari itong magpakilala ng mga kahinaan. Mukhang mayroon kaming nakasulat na reference code, ngunit pagkatapos ay gumawa kami ng mga pagbabago na sumisira sa perpektong pinag-isipang arkitektura.
Ang resulta ay isang hindi ganap na mataas na kalidad na produkto, dahil ang mga patch ay lumitaw na sa arkitektura, ang code sa ilang mga lugar ay hindi sapat na sakop ng mga pagsubok, dahil ang mga deadline ay nauubusan, ang lahat ng mga bug ay kailangang isara nang mabilis. At lahat dahil ang orihinal na detalye ay hindi isinasaalang-alang ang lahat ng mga punto na kailangang ipatupad.
Ang mga developer ay hindi mga peste at hindi nagsusulat ng code na may mga error sa layunin.
Kung una naming naisip ang isang detalye na sumasaklaw sa lahat ng kinakailangang punto, kung gayon ang lahat ay maipapatupad nang eksakto kung kinakailangan. Ngunit ito ay isang utopia.
Malamang na imposibleng magsulat ng perpektong 100-pahinang detalye. kaya lang kailangang mag-isip tungkol sa mga alternatibong paraan ng pagsulat ng dokumentasyon, mga detalye, pagtatakda ng mga gawain na maglalapit sa atin sa pagtiyak na ginagawa ng developer ang eksaktong kailangan.
Dito naiisip ang mga diskarte mula sa Agile - mga kwento ng user na may pamantayan sa pagtanggap. Ito ay mas naaangkop para sa mga koponan na bubuo sa maliliit na pag-ulit.
— Paano naman ang pagsusuri sa kakayahang magamit, kakayahang magamit ng produkto, disenyo?
Анастасия: Ito ay isang napakahalagang punto, dahil may mga taga-disenyo sa koponan. Kadalasan, ginagamit ang mga designer bilang isang serbisyo - alinman sa isang departamento ng disenyo o ng isang outsourced na taga-disenyo. Mayroong madalas na mga sitwasyon kung saan tila nakinig ang taga-disenyo sa espesyalista ng produkto at ginawa ang naiintindihan niya. Ngunit kapag sinimulan namin ang pag-ulit, lumalabas na ang aktwal na ginawa ay hindi ang inaasahan: ang taga-disenyo ay nakalimutan ang isang bagay, hindi lubos na naisip ang pag-uugali, dahil wala siya sa koponan at wala sa konteksto, o sa harap. -hindi lubos na naunawaan ng developer ang layout nito. Maaaring tumagal ng ilang pag-ulit dahil lang may problema sa pag-unawa ng front-end na developer sa disenyo.
Plus may isa pang problema. Ang mga sistema ng disenyo ay nakakakuha na ngayon ng katanyagan. Ang mga ito ay nasa hype, ngunit ang mga benepisyo mula sa kanila ay hindi lubos na halata.
Nakita ko ang opinyon na ang mga sistema ng disenyo, sa isang banda, ay nagpapasimple ng pag-unlad, ngunit sa kabilang banda, nagpapataw sila ng maraming mga paghihigpit sa interface.
Bilang resulta, hindi namin ginagawa ang tampok na gusto ng kliyente, ngunit ang isa na maginhawa para sa amin, dahil mayroon na kaming ilang mga cube kung saan maaari naming gawin ito.
Sa tingin ko ito ay isang paksa na nagkakahalaga ng pagtingin at pag-iisip kung sa pagsisikap na gawing mas madali ang disenyo ay talagang nilulutas namin ang isang punto ng sakit ng kliyente.
— Mayroong nakakagulat na bilang ng mga paksang nauugnay sa Quality Assurance. Mayroon bang kumperensya sa Russia kung saan lahat ng mga ito ay maaaring talakayin?
Анастасия: Mayroong pinakalumang testing conference, na gaganapin sa ika-25 na pagkakataon sa taong ito at tinatawag na SQA Days Quality Assurance Conference. Pangunahing tinatalakay nito ang mga tool at partikular na diskarte sa pagsubok para sa mga functional tester. Bilang panuntunan, malalim na sinusuri ng mga ulat sa SQA Days ang mga partikular na lugar sa lugar ng responsibilidad ng mga tester mismo, ngunit hindi ang mga kumplikadong aktibidad.
Nakakatulong ito nang malaki sa pag-unawa sa iba't ibang mga tool at diskarte, kung paano subukan ang mga database, API, atbp. Ngunit sa parehong oras, sa isang banda, hindi ito nag-uudyok na magsangkot ng higit pa sa pagsubok sa paglikha ng isang mas mahusay na produkto. Sa kabilang banda, ang mga tagasubok ay hindi nagiging mas kasangkot sa proseso upang isipin ang tungkol sa pandaigdigang layunin ng produkto at ang bahagi ng negosyo nito.
Nagpapatakbo ako ng isang malaking departamento at nagsasagawa ako ng maraming panayam na talagang nagbibigay ng pananaw sa estado ng industriya sa kabuuan. Bilang isang patakaran, ang aming mga lalaki ay nagtatrabaho sa mga negosyo, at mayroon silang isang malinaw na lugar ng responsibilidad. Ang mga kasamahan na nagtatrabaho sa mga dayuhang proyekto ay gumagamit ng iba't ibang uri ng pagsubok: sila mismo ay maaaring gumawa ng pagsubok sa pag-load, pagsubok sa pagganap, at kahit minsan ay pagsubok sa seguridad, dahil talagang tinutulungan nila ang koponan na matiyak ang kalidad ng produkto.
Gusto kong simulan din ng mga lalaki sa Russia na isipin na ang industriya ay hindi nagtatapos sa functional testing.
— Para sa layuning ito, nag-oorganisa kami ng bagong kumperensya, ang QualityConf, na nakatuon sa kalidad bilang isang mahalagang disiplina. Sabihin sa amin ang higit pa tungkol sa ideya, ano ang pangunahing layunin ng kumperensya?
Анастасия: Nais naming lumikha ng isang komunidad ng mga taong interesado sa paggawa ng mga de-kalidad na produkto. Mag-alok ng platform kung saan sila makakapunta, makinig sa mga ulat at umalis pagkatapos ng kumperensya na may partikular na pag-unawa sa kung ano ang kailangang baguhin upang mapabuti ang kalidad.
Sa ngayon, madalas kong naririnig ang isang kahilingan mula sa pagkonsulta tungkol sa kung ano ang gagawin kapag may mga problema sa pagsubok at kalidad. Kapag nagsimula kang makipag-usap sa mga koponan, makikita mo na ang problema ay hindi sa mga tester mismo, ngunit sa kung paano nakaayos ang proseso. Halimbawa, kapag naniniwala ang mga developer na sila lang ang may pananagutan sa pagsusulat ng code, ang kanilang responsibilidad ay nagtatapos nang eksakto sa sandaling ibigay nila ang gawain sa pagsubok.
Hindi lahat ay nag-iisip tungkol sa katotohanan na ang hindi magandang nakasulat, mababang kalidad na code na may mahinang arkitektura ay nagbabanta sa malalaking problema para sa proyekto. Hindi nila iniisip ang halaga ng mga error, na ang mga bug na napupunta sa produksyon ay maaaring magresulta sa malalaking gastos para sa kumpanya at sa koponan. Walang kultura na mag-isip tungkol dito. Gusto kong simulan natin itong ipamahagi sa conference.
Naiintindihan ko na hindi ito isang inobasyon. Si Edward Deming, ang may-akda ng 14 na prinsipyo ng kalidad, ay sumulat tungkol sa halaga ng isang error noong nakaraang siglo. Ang Quality Assurance bilang isang disiplina ay batay sa aklat na ito, ngunit, sa kasamaang-palad, nakakalimutan ito ng modernong pag-unlad.
— Plano mo bang direktang hawakan ang mga paksa tungkol sa pagsubok at mga tool?
Анастасия: Inaamin ko na magkakaroon ng mga ulat tungkol sa mga tool. Mayroong medyo unibersal na mga tool kung saan maaaring maimpluwensyahan ng mga kumpanya at koponan ang produkto.
Ang lahat ng mga ulat ay magkakaisa sa buong mundo sa pamamagitan ng isang karaniwang misyon: upang maiparating sa madla na sa tulong ng diskarte, tool, pamamaraan, proseso, uri ng pagsubok na ito, naimpluwensyahan namin ang kalidad ng produkto at napabuti ang buhay ng kliyente.
Tiyak na wala kaming mga ulat tungkol sa isang tool para sa kapakanan ng isang tool. Ang lahat ng mga ulat na kasama sa programa ay pagkakaisa ng isang iisang layunin.
— Sino ang magiging interesado sa iyong pinag-uusapan, na nakikita mo bilang mga panauhin ng kumperensya?
Анастасия: Magkakaroon kami ng mga ulat para sa mga developer na nagmamalasakit sa kapalaran ng kanilang proyekto, produkto, system. Gayundin, magiging interesado ito sa mga tagasubok at, para sa akin, lalo na sa mga tagapamahala. Sa pamamagitan ng mga tagapamahala, ang ibig kong sabihin ay mga taong gumagawa ng mga desisyon at maaaring makaimpluwensya sa kapalaran at pag-unlad ng isang produkto, sistema, pati na rin ng pangkat.
Ito ang mga taong nagtataka kung paano pagbutihin ang kalidad ng isang produkto o sistema. Sa aming kumperensya, malalaman nila ang tungkol sa iba't ibang hanay ng mga hakbang at mauunawaan nila kung ano ang mali sa kanila ngayon at kung ano ang kailangang baguhin.
Sa tingin ko ang pangunahing criterion ay upang maunawaan na may mali sa kalidad at nais na maimpluwensyahan ito. Malamang na hindi natin maaabot ang mga taong nag-iisip na gagawin ito sa unang pagkakataon.
— Sa palagay mo ba ay handa na ang industriya sa kabuuan na pag-usapan hindi lamang ang tungkol sa pagsubok, kundi tungkol sa kultura ng kalidad?
Анастасия: Nagmature na yata ako. Ngayon maraming mga kumpanya ang lumalayo mula sa tradisyonal na diskarte sa Waterfall patungo sa Agile. Mayroong isang focus sa customer, ang mga tao sa mga koponan ay talagang nagsisimulang mag-isip tungkol sa kung paano lumikha ng isang kalidad na produkto. Maging ang mga kumpanya ng enterprise ay muling tumutuon sa pagpapabuti ng kalidad.
Sa paghusga sa bilang ng mga kahilingan na lumalabas sa komunidad, naniniwala ako na oras na. Hindi ako sigurado, siyempre, na ito ay magiging isang malakihang rebolusyon, ngunit gusto kong mangyari ang rebolusyong ito sa kamalayan.
- Sumang-ayon! Ikikintal natin ang kultura at babaguhin ang kamalayan.
Kumperensya sa mataas na kalidad na pag-unlad ng mga produktong IT magaganap sa Moscow noong Hunyo 7. Alam mo kung anong mga yugto ang bumubuo sa isang de-kalidad na produkto, mayroon kaming mga kaso ng matagumpay na paglaban sa mga bug sa produksyon, sinubukan namin ang mga sikat na pamamaraan sa aming pagsasanay - kailangan namin ang iyong karanasan. nila mga aplikasyon bago ang Mayo 1, at ang Komite ng Programa ay tutulong na ituon ang tema para sa pangkalahatang integridad ng kumperensya.
Kumonekta sa , kung saan tinatalakay namin ang mga isyu sa kalidad at ang kumperensya, mag-subscribe sa upang manatiling napapanahon sa balita ng programa.
Pinagmulan: www.habr.com