Bumalik sa paaralan: kung paano sanayin ang mga manu-manong tester upang harapin ang mga awtomatikong pagsubok

Apat sa limang aplikante ng QA ang gustong matuto kung paano magtrabaho sa mga automated na pagsusulit. Hindi lahat ng mga kumpanya ay maaaring matupad ang mga kagustuhan ng mga manu-manong tester sa oras ng trabaho. Nagsagawa si Wrike ng isang automation school para sa mga empleyado at natanto ang pagnanais na ito para sa marami. Nakilahok ako sa paaralang ito bilang isang estudyante ng QA.

Natutunan ko kung paano magtrabaho kasama ang Selenium at ngayon ay hiwalay na sumusuporta sa isang tiyak na bilang ng mga autotest na halos walang tulong sa labas. At, batay sa mga resulta ng aming pinagsamang karanasan at sa aking mga personal na konklusyon, susubukan kong kunin ang mismong pormula para sa pinakaperpektong paaralan ng automation.

Ang karanasan ni Wrike sa pag-oorganisa ng paaralan

Nang maging malinaw ang pangangailangan para sa isang paaralan ng automation, nahulog ang organisasyon nito kay Stas Davydov, ang teknikal na pinuno ng automation. Sino pa ba kundi siya ang makakapagpaliwanag kung bakit nila ginawa ang inisyatiba na ito, kung nakamit ba nila ang mga resulta at kung pinagsisisihan nila ang oras na ginugol? Bigyan natin siya ng sahig:

β€” Noong 2016, sumulat kami ng bagong balangkas para sa mga autotest at ginawa ito upang maging madali ang pagsulat ng mga pagsubok: lumitaw ang mga normal na hakbang, ang istraktura ay naging mas naiintindihan. Nakaisip kami ng ideya: kailangan naming isali ang lahat ng gustong magsulat ng mga bagong pagsubok, at para mas madaling maunawaan, gumawa kami ng serye ng mga lecture. Sama-sama kaming nakabuo ng isang plano ng mga paksa, bawat isa sa mga hinaharap na lektor ay kumuha ng isa para sa kanilang sarili at naghanda ng isang ulat tungkol dito.

β€” Ano ang mga kahirapan ng mga mag-aaral?

β€” Pangunahin, siyempre, arkitektura. Maraming tanong tungkol sa istruktura ng aming mga pagsusulit. Sa feedback, marami ang naisulat sa paksang ito at kinailangan naming magdaos ng karagdagang mga lektura upang maipaliwanag nang mas detalyado.

β€” Nagbayad ba ang paaralan?

- Oo, tiyak. Salamat sa kanya, maraming tao ang kasangkot sa pagsulat ng mga pagsusulit, at, sa karaniwan, sa ospital, ang lahat ay nagsimulang mas maunawaan kung ano ang mga autotest, kung paano ito isinulat at kung paano sila inilunsad. Nabawasan din ang pagkarga sa mga inhinyero ng automation: nakatanggap na kami ngayon ng maraming beses na mas kaunting mga kahilingan para sa tulong sa pagsusuri ng mga pagsubok, dahil sinimulan na ng mga tester at developer na makayanan ito mismo sa halos lahat ng sitwasyon. Well, mayroong ilang mga panloob na pakinabang para sa departamento: nakakuha kami ng karanasan sa mga presentasyon at mga lektura, salamat sa kung saan ang ilang mga inhinyero ng automation ay nakapagsagawa na ng mga presentasyon sa mga kumperensya, at nakatanggap din ng isang malakas na hanay ng mga video at mga presentasyon para sa mga bagong dating.

Sa aking sariling ngalan, idaragdag ko na ang komunikasyon sa pagitan ng aming mga departamento ay pinasimple sa isang napakadaling antas. Halimbawa, ngayon halos hindi ko na kailangang isipin kung aling mga kaso at sa anong antas ng atomicity ang i-automate. Bilang resulta, ang lahat ng mga interesadong partido ay lubos na nag-aalaga sa saklaw ng pagsubok, na patuloy na lumalaki. Walang humihingi ng imposible sa iba.

Sa pangkalahatan, ang epekto sa gawain ng mga koponan ay tiyak na positibo. Marahil ang mga kasamahan na nagbabasa ng artikulong ito ay nag-iisip din tungkol sa paggawa ng katulad na bagay? Kung gayon ang payo ay magiging simple: sulit kung priyoridad mo ang mga automated na pagsubok. Susunod, pag-uusapan natin ang tungkol sa isang mas kumplikadong tanong: kung paano ayusin ang lahat ng ito nang tama hangga't maaari, upang ang mga gastos ng lahat ng partido ay minimal at ang output ay maximum.

Mga Tip sa Pag-aayos

Ang paaralan ay kapaki-pakinabang, ngunit, tulad ng inamin ni Stas, mayroong ilang mga paghihirap, dahil kung saan kinakailangan upang ayusin ang mga karagdagang lektura. At ito ay bilang isang kamakailang mag-aaral na naghahambing sa aking sarili-sa-kamangmangan at sa aking sarili-ngayon na binuo ko ang mga sumusunod na hakbang upang lumikha, sa aking opinyon, ang perpektong paraan upang turuan ang mga tester na maunawaan ang mga awtomatikong pagsusulit.

Hakbang 0. Gumawa ng diksyunaryo

Siyempre, ang hakbang na ito ay kailangan hindi lamang para sa QA. Gayunpaman, gusto kong gawin itong tahasan: ang automation codebase ay dapat panatilihin sa isang nababasang anyo. Mga wika sa programming - hindi bababa sa mga wika, at mula dito maaari mong simulan ang iyong pagsisid.

Bumalik sa paaralan: kung paano sanayin ang mga manu-manong tester upang harapin ang mga awtomatikong pagsubok

Narito ang isang screenshot ng isang taskview na may mga pangalan ng mga elemento. Isipin natin na sinusubukan mo ang taskview bilang isang black box at hindi mo pa nakita ang Selenium sa iyong buhay. Ano ang ginagawa ng code na ito?

Bumalik sa paaralan: kung paano sanayin ang mga manu-manong tester upang harapin ang mga awtomatikong pagsubok

(Spoiler - ang gawain ay tinanggal sa pamamagitan ng pahinga sa ngalan ng admin, at pagkatapos ay nakita namin na mayroong isang talaan nito sa stream.)

Ang hakbang na ito lamang ang naglalapit sa mga wika ng QAA at QA. Mas madali para sa mga automation team na ipaliwanag ang mga resulta ng isang run; ang mga manu-manong tester ay kailangang gumastos ng mas kaunting pagsisikap sa paggawa ng mga kaso: maaari silang gawing hindi gaanong detalyado. Gayunpaman, nagkakaintindihan ang bawat isa. Natanggap namin ang mga panalo bago pa man magsimula ang aktwal na pagsasanay.

Hakbang 1. Ulitin ang mga parirala

Ipagpatuloy natin ang parallel sa wika. Kapag natuto tayong magsalita bilang mga bata, hindi tayo nagsisimula sa etimolohiya at semantika. Inuulit namin ang "nanay", "bumili ng laruan", ngunit hindi kaagad pumunta sa Proto-Indo-European na mga ugat ng mga salitang ito. Kaya ito ay narito: walang punto sa pagsisid sa pinakalalim ng mga teknikal na tampok ng mga autotest nang hindi sinusubukang magsulat ng isang bagay na gumagana.
Ito ay tunog ng isang maliit na counterintuitive, ngunit ito ay gumagana.

Sa unang aralin, ito ay nagkakahalaga ng pagbibigay ng batayan kung paano direktang sumulat ng mga autotest. Tumutulong kami sa pag-set up ng development environment (sa aking kaso, Intellij IDEA), ipaliwanag ang mga minimum na panuntunan sa wika na kinakailangan upang magsulat ng isa pang paraan sa isang umiiral na klase gamit ang mga kasalukuyang hakbang. Sumulat kami ng isa o dalawang pagsubok sa kanila at binibigyan sila ng araling-bahay, na ipo-format ko tulad nito: isang sangay na nagsanga mula sa master, ngunit maraming mga pagsubok ang tinanggal mula dito. Tanging ang kanilang mga paglalarawan ang natitira. Hinihiling namin sa mga tester na ibalik ang mga pagsubok na ito (hindi sa pamamagitan ng show diff, siyempre).

Bilang resulta, ang nakinig at ginawa ang lahat ay magagawang:

  1. matutong magtrabaho kasama ang interface ng development environment: paglikha ng mga branch, hotkey, commits at pushes;
  2. master ang mga pangunahing kaalaman ng istraktura ng wika at mga klase: kung saan magpasok ng mga iniksyon at kung saan mag-import, bakit kailangan ang mga anotasyon, at anong uri ng mga simbolo ang matatagpuan doon, bukod sa mga hakbang;
  3. maunawaan ang pagkakaiba sa pagitan ng aksyon, maghintay at suriin, kung saan gagamitin kung ano;
  4. pansinin ang pagkakaiba sa pagitan ng mga autotest at manu-manong pagsusuri: sa mga autotest maaari mong hilahin ang isa o isa pang handler sa halip na magsagawa ng mga aksyon sa pamamagitan ng interface. Halimbawa, direktang magpadala ng komento sa backend sa halip na magbukas ng taskview, piliin ang input, mag-type ng text at i-click ang Send button;
  5. bumalangkas ng mga tanong na sasagutin sa susunod na hakbang.

Ang huling punto ay napakahalaga. Ang mga sagot na ito ay madaling maibigay nang maaga, ngunit ito ay isang mahalagang alituntunin sa pagtuturo na ang mga sagot na walang nabuong mga tanong ay hindi naaalala at hindi ginagamit kapag sa wakas ay kailangan.

Magiging mainam kung sa oras na ito ang isang automation engineer mula sa QA team ay nagtalaga sa kanya ng isang gawain sa pagsulat ng ilang mga pagsubok sa labanan at pinapayagan siyang mag-subcommit sa kanyang sangay.

Ano ang hindi dapat ibigay:

  1. mas malalim na kaalaman sa functionality ng development environment at ang programming language mismo, na kakailanganin lamang kapag nagtatrabaho sa mga branch nang nakapag-iisa. Hindi ito maaalala, kailangan mong ipaliwanag ito ng dalawang beses o tatlong beses, ngunit pinahahalagahan namin ang oras ng mga inhinyero ng automation, tama ba? Mga halimbawa: paglutas ng mga salungatan, pagdaragdag ng mga file sa git, paglikha ng mga klase mula sa simula, pagtatrabaho sa mga dependency;
  2. lahat ng may kinalaman sa xpath. Seryoso. Kailangan mong pag-usapan ito nang hiwalay, isang beses at napaka-puro.

Hakbang 2. Pagsusuri sa gramatika

Tandaan natin ang screenshot ng taskview mula sa hakbang #0. Mayroon kaming hakbang na tinatawag na checkCommentWithTextExists. Naiintindihan na ng aming tester kung ano ang ginagawa ng hakbang na ito at maaari naming tingnan ang loob ng hakbang at mabulok ito nang kaunti.

At sa loob mayroon kaming sumusunod:

onCommentBlock(userName).comment(expectedText).should(displayed());

Nasaan ang onCommentBlock

onCommonStreamPanel().commentBlock(userName);

Ngayon natutunan nating sabihin na hindi "bumili ng laruan," ngunit "bumili ng laruan mula sa Detsky Mir store, na matatagpuan sa asul na cabinet sa ikatlong istante mula sa itaas." Kinakailangang ipaliwanag na itinuturo namin ang isang elemento nang sunud-sunod, mula sa mas malalaking elemento (stream -> block na may mga komento mula sa isang partikular na tao -> ang bahagi ng bloke na ito kung saan nakaupo ang tinukoy na teksto).

Hindi, hindi pa oras para pag-usapan ang xpath. Banggitin lamang nang maikli na ang lahat ng mga tagubiling ito ay inilarawan nila at ang mana ay dumadaan sa kanila. Ngunit kailangan nating pag-usapan ang lahat ng mga matcher at waiter na ito; partikular na nauugnay ang mga ito sa hakbang na ito at kinakailangan upang maunawaan kung ano ang nangyayari. Ngunit huwag mag-overload: ang iyong mag-aaral ay maaaring mag-aral ng mas kumplikadong mga pahayag sa kanyang sarili mamaya. Malamang, dapat, waitUntil, displayed();, exist();, not(); dapat sapat na.

Ang araling-bahay ay halata: isang sangay kung saan ang mga nilalaman ng ilang hakbang na kinakailangan para sa isang tiyak na bilang ng mga pagsubok ay inalis. Hayaang ibalik ng mga tester ang mga ito at gawing berdeng muli ang pagtakbo.

Bukod pa rito, kung ang pangkat ng pagsubok ay may hindi lamang mga bagong tampok sa trabaho nito, kundi pati na rin ang ilang mga pag-aayos ng bug, maaari mong hilingin sa kanya na agad na magsulat ng mga pagsubok para sa mga bug na ito at ilabas ang mga ito. Malamang, ang lahat ng mga elemento ay inilarawan na; ilang hakbang na lang ang maaaring kulang. Ito ang magiging perpektong ehersisyo.

Hakbang 3. Buong paglulubog

Bilang kumpleto hangga't maaari para sa isang tester na magpapatuloy sa kanyang mga direktang tungkulin. Sa wakas, kailangan nating pag-usapan ang tungkol sa xpath.

Una, gawin nating malinaw na ang lahat ng ito saCommentBlock at komento ay inilarawan nila.

Bumalik sa paaralan: kung paano sanayin ang mga manu-manong tester upang harapin ang mga awtomatikong pagsubok

Kabuuan:

"//div[contains(@class, β€˜stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"

Napakahalaga ng pagkakasunud-sunod ng kwento. Una, kinukuha namin ang anumang umiiral na xpath at ipinapakita kung paano naglalaman ang tab ng mga elemento ng isa at isang elemento lamang. Susunod, pag-uusapan natin ang tungkol sa istraktura: kapag kailangan mong gumamit ng WebElement, at kapag kailangan mong lumikha ng isang hiwalay na file para sa isang bagong elemento. Ito ay magbibigay-daan sa iyo upang mas maunawaan ang mana.

Dapat itong tahasang nakasaad na ang isang elemento ay ang buong taskview, naglalaman ito ng child element - ang buong stream, na naglalaman ng child element - isang hiwalay na komento, atbp. Ang mga elemento ng bata ay nasa loob ng mga elemento ng magulang sa parehong pahina at sa istruktura ng autotest framework.

Sa puntong ito, dapat ay lubos na naunawaan ng audience kung paano sila namamana at kung ano ang maaaring ilagay pagkatapos ng tuldok sa onCommentBlock. Sa puntong ito, ipinapaliwanag namin ang lahat ng mga operator: /, //, ., [] at iba pa. Nagdaragdag kami ng kaalaman tungkol sa paggamit sa load @class at iba pang kinakailangang bagay.

Bumalik sa paaralan: kung paano sanayin ang mga manu-manong tester upang harapin ang mga awtomatikong pagsubok

Dapat na maunawaan ng mga mag-aaral kung paano isalin ang xpath sa ganitong paraan. Upang pagsama-samahin - tama iyon, araling-bahay. Tinatanggal namin ang mga paglalarawan ng mga elemento, hayaan silang ibalik ang gawain ng mga pagsubok.

Bakit ito partikular na landas?

Hindi natin dapat i-overload ang isang tao na may kumplikadong kaalaman, ngunit dapat nating ipaliwanag ang lahat nang sabay-sabay, at ito ay isang mahirap na problema. Ang landas na ito ay magbibigay-daan sa amin na magtanong muna sa mga tagapakinig at hindi maunawaan ang isang bagay at sagutin sila sa susunod na sandali. Kung pinag-uusapan mo ang buong arkitektura, pagkatapos ay sa oras na ang paksa ng mga hakbang o xpath ay nasuri, ang pinakamahalagang bahagi nito ay malilimutan na dahil sa kanilang hindi maunawaan.

Gayunpaman, malamang na maibabahagi ng ilan sa inyo ang iyong karanasan sa kung paano mas ma-optimize ang proseso. Ako ay magiging masaya na basahin ang mga katulad na mungkahi sa mga komento!

Pinagmulan: www.habr.com

Magdagdag ng komento