Dumaan sa tatlong henerasyon ang browser automation. Nilutas ng bawat isa ang pangunahing bottleneck ng nauna, ngunit inilipat din nito ang susunod na bottleneck sa ibang bahagi. Mas mahalagang unawain ang problemang naiiwan ng bawat henerasyon kaysa kabisaduhin ang mga pangalan ng tool.
Mahigit dalawampung taon nang ginagamit ang browser automation, at tatlong beses nang nagbago ang pangunahing direksiyon nito. Ang kapansin-pansin ay magkaibang uri ng problema ang nilulutas ng bawat henerasyon, at kapag nalutas ang isa, lumilipat lamang ang bottleneck sa ibang bahagi.
Unang henerasyon: magkunwaring may taong gumagalaw ng mouse sa antas ng operating system
Ang pinakaunang automation ay hindi talaga ginagawa sa loob ng browser. Ginagawa ito sa antas ng operating system. Iginagalaw ng script ang mouse at pinipindot ang mga key, habang tumatanggap lamang ang browser ng mga input na iyon.
Ang bentahe nito ay pagiging pangkalahatan: anumang nakikita sa screen ay maaari nitong galawin, maging web page, client application, o lumang desktop software, at hindi kailangang magbigay ang browser ng anumang interface. Direktang kapalit nito ang pagiging marupok. Nakasalalay ang script sa screen coordinates, kaya kapag nagbago ang resolution, system scaling, o puwesto ng window, maaari nang tumama sa maling lugar ang parehong aksiyon. Hindi rin nito alam kung tapos nang mag-load ang page, kaya umaasa lamang ito sa fixed wait. Mas mahirap pa ang parallel execution: iisa lang ang mouse at keyboard ng isang machine, kaya sampung environment ay nangangailangan ng sampung machine.
Simple ang problemang naiwan ng henerasyong ito: hindi nito nakikita ang page.
Ikalawang henerasyon: lampasan ang screen at direktang makipag-usap sa browser
Inilipat ng pagdating ng WebDriver ang automation mula sa antas ng pixel patungo sa antas ng element: hinahanap na nito ang isang partikular na element sa page sa halip na ang posisyon ng ika-800 pixel sa screen. Magagamit ang parehong code sa iba’t ibang browser at maisusulat sa iba’t ibang programming language, kaya naging pamantayan rin ito sa testing.
Paglaon, lalo pang pinalawak ng mga solusyong nakabatay sa browser debugging protocol ang direksiyong ito. Direktang nakikipag-ugnayan sa browser engine ang Puppeteer at Playwright at nakakakuha ng internal page state: awtomatikong paghihintay hanggang maging handa ang element, pag-intercept at pag-rewrite ng request, pagkonekta sa nakabukas nang browser instance, headless execution, at sabay-sabay na pagbubukas ng maraming context. Marami sa mga kakayahang karaniwan na ngayon ay nabuo sa yugtong ito.
Nalutas nito ang control at stability, ngunit may dalawang problemang naiwan. Una, tao pa rin ang mahigpit na nagsusulat ng script. Kapag nagbago ang page structure o nasira ang selector, kailangang baguhin ang code, at tumataas ang maintenance cost habang lumalaki ang proyekto. Ikalawa, may mas pundamental na limitasyon: pinamamahalaan nito kung paano gagawin ang operasyon, hindi kung kanino ito magmumukhang nanggaling. Mas eksakto ang control sa direktang protocol connection, ngunit hindi nawawala ang bakas ng automation dahil lamang sa pagbabago ng paraan ng komunikasyon. Kahit napakatatag ng script, maaari pa rin itong magmukhang script sa iba.
Ikatlong henerasyon: hindi na tao ang nagsusulat ng bawat hakbang, at lumipat muli ang problema
Sa ikatlong henerasyon, hindi ang paraan ng control ang nagbago kundi ang paraan ng decision-making. Sa unang dalawang henerasyon, kailangang isa-isahin ng tao ang bawat hakbang: anong button ang iki-click, anong field ang pupunan, at sa anong pagkakasunod-sunod. Sa model-driven generation, ibinibigay ang layunin, ang model ang nagpaplano ng ruta, at kaya nitong humanap muli ng entry point kapag nagbago ang disenyo ng page.
Dahil dito, unti-unting nababawasan ang bigat ng mga dating masalimuot na detalye gaya ng pagsulat ng selector at haba ng paghihintay. Ngunit agad ding lumilitaw ang mga bagong problema.
Ang mahalagang punto ay hindi ang model mismo ang bumibisita sa web page. Browser pa rin ang nagbubukas ng page, naglo-load ng resources, at nagpapanatili ng login state. Kaya kapag naging hindi matatag ang isang task, madalas ay hindi maling desisyon ng model ang dahilan kundi ang execution environment sa ilalim nito: maraming task ang gumagamit ng iisang browser at naghahalo ang cookies at cache; masyadong magkakahawig ang fingerprint characteristics kaya nakikita ng platform na mula sa iisang machine ang mga task; nagagamit ang accounts sa iba’t ibang task kaya maaaring makaapekto sa marami ang isang anomaly; kailangang pansamantalang gumawa ng environment at bawiin ito pagkatapos gamitin, ngunit walang iisang scheduling system. Nalulutas ng model ang tanong na paano gawin ang task, kaya ang tanong na saan ito gagawin ang nagiging bagong bottleneck.
Ang dagdag na layer sa architecture
Kapag pinagsama ang tatlong henerasyon, hindi simpleng usapin kung alin ang mas advanced. Kailangang saluhin ng bawat henerasyon ang hindi nalutas ng nauna. Sa unang dalawang henerasyon, hindi malaking problema ang environment dahil browser sa sariling machine ang ginagamit. Sa Agent stage, maramihan, sabay-sabay, at unattended ang mga task, kaya kailangang tahasang pamahalaan ang environment: bawat task ay tumatakbo sa hiwalay na environment, hindi naghahalo ang fingerprints at sessions; napapanatili ang login state sa pagitan ng mga task para hindi kailangang mag-login muli sa bawat pagkakataon; magkatugma ang IP, time zone, at language bilang isang set; at ginagawa at binabawi ang mga environment on demand na parang computing resources.
Dito mismo gumagana ang PurpleMark: ginagawa nitong schedulable resources ang mga browser environment para makapagpokus ang Agent sa task logic.
Mas madaling ilagay sa tamang konteksto ang pagpili. Maaaring manatili sa kasalukuyang direksiyon ang enterprise testing stacks at umiiral na script assets; ang mga komplikadong web application na nangangailangan ng request-level control ay babagay sa protocol-driven generation; at para sa mga task na pinaplano ng model at kailangang tumakbo nang matatag sa mahabang panahon, magagamit pa rin ang teknolohiya ng unang dalawang henerasyon ngunit kailangang lutasin nang hiwalay ang environment layer. Kung kailangang magmukhang tunay na user ang gumagawa ng operasyon, hindi iyon kayang ibigay ng automation framework nang mag-isa, anuman ang henerasyon.
May isa pang hangganan bukod sa teknikal na ruta: kailangang sumunod ang automated operations sa mga patakaran ng target platform at sa lokal na batas. Ang pagiging posible sa teknikal na aspeto ay hindi awtomatikong nangangahulugang angkop ito sa negosyo.
