Run Selenium Tests in Azure Devops
You can run selenium tests in azure devops by adding a test task to your build pipeline. The pipeline starts a browser driver on the build agent and executes your test suite against your target web app. Many teams set up these pipelines with broad agent roles so tests can seed databases and check cloud services. When pipeline permissions are too wide, any script on the agent can read or change sensitive data. How to run selenium tests in azure devops pipelines First, your team stores the test
Just-in-Time Access + Azure RBAC: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You can run selenium tests in azure devops by adding a test task to your build pipeline. The pipeline starts a browser driver on the build agent and executes your test suite against your target web app. Many teams set up these pipelines with broad agent roles so tests can seed databases and check cloud services. When pipeline permissions are too wide, any script on the agent can read or change sensitive data.
How to run selenium tests in azure devops pipelines
First, your team stores the test code in a source control repo. You then define a build or release pipeline in your project. This pipeline uses either a cloud-hosted agent or a self-hosted machine. Hosted agents already include common web browsers and matching browser drivers. If you use your own machine, you must install the browsers and drivers yourself.
Next, the pipeline pulls your code and compiles the test project. It installs the needed packages and starts the test runner task. The test runner opens the browser in headless mode on the agent. Headless mode runs the browser without a visible screen, which saves memory and speeds up the run.
During the run, the browser talks to your deployed staging app over the network. Many test suites also connect straight to a backend database to set up test users or clean up old records. When the suite finishes, the pipeline collects the output files and screenshots. A publish task then reads these files and shows pass or fail charts on your build summary page.
Why pipeline roles and secrets need tighter bounds
Native pipeline tools handle job scheduling and result charts well. They let you store database passwords and cloud keys inside secret variable groups. You can also restrict which pipelines can read those variable groups. This native setup controls which agent or job can log in to your backend systems.
Still, a major security gap keeps the session active during the test run itself. Once the agent pulls a secret key or database password, the whole job holds that role. The native setup decides who logs in, not what individual statements or commands do in flight. A broken test script could run a drop table command by mistake. A bad package inside the test build could also query customer emails or card numbers from a shared staging database.
Just-in-Time Access + Azure RBAC: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing test agent access to backend data
Teams often copy real data into staging databases to make browser tests realistic. When you do this, test agents gain wide read access to sensitive fields. Even if you trust your engineers, automated jobs run code from many third-party libraries. Static pipeline secrets give every library in the test run full access to the database.
To lower this risk, teams separate browser actions from backend setup commands. You should give the test agent the smallest role needed for its job. You also need visibility into every query the agent sends during a pipeline run. Auditing individual queries and masking sensitive fields like phone numbers or national IDs in results keeps test runs safe.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Should I use a hosted agent or a self-hosted agent for browser tests?
Hosted agents work best for public or cloud staging apps because they come with browsers pre-installed. Self-hosted agents are better when your test suite must reach private internal networks or local test databases.
Why do my browser tests fail only when running inside the pipeline?
Pipeline agents usually run browsers in headless mode with a small default screen size. Hidden buttons, slow network calls, or missing firewall rules between the agent and the staging app often cause these failures.
How can I protect staging databases during automated test runs?
Avoid using admin database accounts in your pipeline variable groups. Restrict the test role to specific tables, log every query sent by the agent, and mask fields like emails and card numbers in query results.