Menu
Home
Forums
New posts
Search forums
What's new
New posts
New media
New media comments
New profile posts
Latest activity
Media
New media
New comments
Search media
Members
Current visitors
New profile posts
Search profile posts
Account Upgrades
Advertise
Marketplace
Money
PerfectMoney
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Home
Forums
Programming & Web Design
Scripting
General Scripting Chat
Where does browser automation usually break first in real projects?
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Randall Graham" data-source="post: 29075" data-attributes="member: 11342"><p>Most browser automation demos look great because they only show the happy path.</p><p></p><p>The browser opens, clicks the correct buttons, submits the form, and everything is done in thirty seconds.</p><p></p><p>Real workflows usually fail in much less exciting ways. A login expires. A selector changes. The proxy becomes slow. A popup appears. The page loads in a different order. The script keeps running, but the final result is wrong.</p><p></p><p>That last case is the one I find most difficult. A clear crash is easy to notice. A workflow that finishes successfully but produces a bad result is much more dangerous.</p><p></p><p>For people running browser automation every day, how do you handle unexpected page states? Do you stop the workflow, retry it, or send it to a human review queue?</p><p></p><p>For me, making the browser perform an action once isn’t the hard part. The hard part is knowing when the result shouldn’t be trusted.</p></blockquote><p></p>
[QUOTE="Randall Graham, post: 29075, member: 11342"] Most browser automation demos look great because they only show the happy path. The browser opens, clicks the correct buttons, submits the form, and everything is done in thirty seconds. Real workflows usually fail in much less exciting ways. A login expires. A selector changes. The proxy becomes slow. A popup appears. The page loads in a different order. The script keeps running, but the final result is wrong. That last case is the one I find most difficult. A clear crash is easy to notice. A workflow that finishes successfully but produces a bad result is much more dangerous. For people running browser automation every day, how do you handle unexpected page states? Do you stop the workflow, retry it, or send it to a human review queue? For me, making the browser perform an action once isn’t the hard part. The hard part is knowing when the result shouldn’t be trusted. [/QUOTE]
Name
Verification
Post reply
Home
Forums
Programming & Web Design
Scripting
General Scripting Chat
Where does browser automation usually break first in real projects?
Top