Browser-based test automation: collaboration tips

11 Dec 2025 🔖 web development tips
💬 EN

Hot take: developers, not QAs, should implement browser-based end-to-end test automations. Hello Playwright / Cypress / Selenium / Puppeteer / etc. Goodbye BrowserStack Low-Code Automation / etc.

Do I have your attention? Yay! That said, it’s just a suggestion, and you can totally do an amazing job of developing software when QAs implement such automations.

Read on for my full opinion.

---

What is browser-based test automation?

Browser-based test automation means testing web sites by using software to control a web browser.

Instead of clicking and typing by hand within the web browser, you write scripts or use tools that do it for you.

• Note:  Whether automated or manual, browser-based testing is typically considered part of the end-to-end testing level of the software testing pyramid philosophy.

---

Why developers should implement browser-based test automation

Although automating software tests almost always delivers a return on investment (“ROI”), long-term ROI is likely to be highest when developers, rather than quality assurance (“QA”) staff (“QAs”), take primary responsibility for implementing and maintaining automated tests as part of their regular workflow. Here’s why:

• Tight integration:  Tests become part of developers’ build process, not a process done afterwards.  This leads to more reliable, maintainable code and fewer “works on my machine” surprises.
  • The DevOps Handbook (1st edition, p. 130) writes:

    “In short, slow and periodic feedback kills. … We need fast automated tests that run … whenever a new change is introduced into version control. In this way, we can find and fix any problems immediately.”

• Immediate feedback:  When developers write and run automated tests as they code, they get instant feedback.  Developers can catch bugs before the code leaves their laptop.
• Fast iteration:  Developers can refactor both code and tests together, keeping everything in sync and reducing technical debt.
• Test-driven development (TDD):  When developers own both application code and test automation code, it becomes easier to consider coding the tests first.
  • A TDD mindset is one of The DevOps Handbook’s six tips for building a fast and reliable automated validation test suite.

---

The role of QA when developers automate tests

• Test case design:  QAs are uniquely skilled at thinking through edge cases, boundary values, and real-world scenarios.
  • For example, when a developer is unsure which values to test a function against, a QA might suggest:

    Please try all of the following:

    • 0
    • 1
    • 3
    • -1
    • 1000000000
    • the word ‘three’
    • ‘3’ as text
    • an empty string
    • null
    • True
    • False
    • a list of numbers

• Implementation-oriented specification:  Writing a detailed test case, with all the inputs and expected results, might almost feel like the QAs are doing the implementation.  That’s a good thing! One of the ways that QAs can accelerate a team of developers is by making the “what to test” so clear that “how to test it” becomes almost mechanical for the developers to implement the actual test automation code.
• Pair programming and collaboration:  Pairing up with a QA for a few minutes can save a developer hours of guesswork, and can ensure robust test coverage.  QAs: encourage your developers to ask questions early and often.

---

Ways developers can initiate collaboration with QA

• Request help regularly:  Ask QA teammates early and often for guidance on tricky scenarios, edge cases, and test data.  Don’t be afraid to ask the “silly” questions – you never know what QAs might be able to answer in minutes, saving you hours.
• Solicit feedback as you code:  Implement tests faster by inviting QAs to join you in pair programming sessions or other quick feedback loops:
  • QAs specify the “what.”
  • Developers implement the “how.”
  • Both review the results.
• Try TDD together:  Even the best-written test case specifications can hit snags when it’s time to turn them into code, frustrating TDD efforts and increasing temptation to “just write the tests later.”  Pair programming with QAs can:
  • Clarify requirements before confusion becomes show-stopping.
  • Prevent misunderstandings about expected behavior.
  • Provide clear targets, so developers are never left guessing “what should I test?”

---

Benefits of tight developer-QA collaboration cycles (e.g. pair programming)

• Developers get fast, reliable feedback and own the quality of their changes.
• QAs focus on higher-value activities and avoid maintaining redundant tests, while their expertise in test design becomes more central.
• The team benefits from faster releases, fewer bugs, and a culture of shared quality ownership.

---

What if our team’s QAs currently implement test automation?

It’s common (and perfectly acceptable) for QA staff to lead the way and implement browser-based test automation themselves. This makes sense:

• QAs already have deep knowledge of an application and its test cases.
• QAs are already familiar with testing the application in a web browser.

Constraints like staffing, skillsets, interest, or legacy processes may also play a role in whether QAs or developers begin a team’s journey into browser-based test automation.

Maybe that’s what led you to invest in a low-code tool such as BrowserStack Low-Code Automation.

Cool!

First, congratulate yourselves on your team’s investment in faster feedback loops and higher quality.

But then, consider whether beginning a hybrid approach to increase developer participation might eventually be the right choice for your team:

• Build for transition:  As QAs automate:
  • Document the automated test cases so developers can pick up the baton later.
  • Publish the automated test results to collaboration tools such as Azure DevOps Test Plans Test Runs.
• Collaborate early:  Encourage developers to:
  • Review, run, and gradually contribute to the automated test suite that the QAs are building.
  • Try implementing the same tests in more developer-oriented tools, if applicable.
  • Practice auto-publishing test results wherever the QAs currently publish theirs.

---

Should developers take over QAs’ tools and suites?

Not necessarily.

It’s okay to have the automated tests that QAs still maintain live one place (e.g. a BrowserStack Low-Code Automation subscription), while the developers start their own parallel automation project using the frameworks, languages, and workflows that best fit their development process. (e.g. Playwright / Cypress / Selenium / Puppeteer / etc.)

As developers’ coverage grows, they can notify QAs which test cases are now covered in the developer-owned automation suite.

Although this strategy adds complexity by introducing an extra test suite, it can also lower risk by making changes more incremental.

• Tool takeover not required:  QAs can keep full ownership of their browser-based test automation tools and suites.  Developers can build their own browser-based test automations, from scratch, in their preferred environment.
• Clear handoffs:  When a test case becomes covered by the developer suite (including automatic result publication), developers should notify QAs.  QAs can then safely remove that test case’s automation from their suite, reducing duplication and maintenance overhead.
• Respect for expertise:  QAs will become free to focus on their strong expertise in test design, exploratory testing, and edge cases.  Developers can focus on integrating browser-based test automation into the application’s overall software development lifecycle automations, just like they regularly integrate so many other automations via CI/CD.

---

Bottom line

Start where you are, but aim to build a culture where developers embrace automating browser-based tests, and partner regularly with QAs to expedite implementation.

Automation delivers the most value in teams that collaborate, ask questions, and value each other’s expertise.

---

Author’s note

I can tell from the formatting that I totally got LLM help writing this article. I’ve edited it so many times over the last year, waiting to bring it to press, that I no longer at all remember who did what. Sorry if it looks like AI slop with all the boldfaced bullets; I swear I’ve read it and actually think it’s covering good points. 😅