Already live in the product
Live in the product today: the ProQA workspace with test cases, plans and runs, the release gate, the Chromium browser matrix with visual baselines, traceability, defects and PDF run reports.
/proqa-agentBuilt around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
What teams can do here
How it works
A worked example
Picture a six-person product team that ships its customer portal every Thursday. The release plan holds five cases: a smoke check that the login page returns 200 and contains “Sign in”, an API check on the health endpoint, a k6 load test at the default 10 virtual users for 30 seconds with a p95 budget of 800 ms, a Lighthouse audit of the home page and a passive ZAP scan. After deploying to staging, the CI job calls the plan’s webhook. When the run finishes, the QA lead opens the browser matrix, compares the new checkout page against last week’s baseline at all three viewport sizes, and spots a 3% pixel difference on the tablet layout. She logs a defect with an assignee and rejects the gate. Friday’s fix reruns green, the gate is approved, and the PDF run report goes out with the release notes.
Chromium only, and what “mobile” means here
ProQA is honest about its browser coverage because a test report is only useful if you can trust it. Every browser check runs in headless Chromium. Firefox and Safari (WebKit) are not installed, and the matrix records them as not configured, never as passed. If your users sit on Chrome or Edge, Chromium tells you most of what you need. If a large part of your traffic is on Safari, keep a manual pass on a real Apple device in your release checklist.
The tablet and mobile presets change only the window size, to 820 × 1180 and 390 × 844, inside the same Chromium. There is no mobile user agent, touch input or device emulation, and there are no Android emulators, iOS simulators or phone farms behind the scenes. That makes the matrix a good tool for catching a layout that collapses at phone width. It is not a substitute for testing a native app.
Quality checks beyond “the page loads”
A green status code says the server answered, but it does not say the release is good. ProQA groups its checks into pillars so each release plan can carry the evidence that fits it. Performance: k6 load tests against p95 latency and error-rate budgets you set, starting from 10 virtual users for 30 seconds. Page quality: Lighthouse scores for performance, accessibility, best practices and SEO. Security hygiene: OWASP ZAP spidering with a passive scan (active scanning is opt-in) and Nuclei templates. Supply chain: point Trivy at a Git repository or container image for dependency CVEs, an SBOM package count and infrastructure-as-code issues, while Semgrep and TruffleHog look for risky code patterns and leaked secrets.
Two more checks are useful for teams shipping AI features or handling personal data. The chatbot checks send red-team prompts to your own bot’s URL and score the answers for groundedness and bias with deterministic rules. The OCR scan reads screenshots or images, flags Aadhaar, PAN, card numbers, phone numbers and email addresses, and masks them. For a full scoped security engagement with analyst triage, use VAPT instead; ProQA’s scans are release hygiene, not a penetration test.
Traceability, defects and release sign-off
Testing produces decisions, and ProQA keeps a record of each one. A requirement reference on a test case feeds the traceability matrix, which shows for each requirement which cases cover it, their latest status, and the coverage and pass rates. Defects are logged with a severity and an assignee and move through their own lifecycle, so mean time to resolve is measured rather than guessed.
When a job fails, a rule-based root-cause draft is attached for a person to approve or reject, and approved lessons go into a knowledge base that brings up similar past failures next time. Analytics track pass-rate trends and flag flaky tests whose result keeps flipping between runs. When a plan requires a release gate, an admin approves or rejects the run. Approvers get an in-app notice and an email when a gate is waiting, and a defect’s assignee is told the same way.
What the DevOps & ProQA add-on includes
DevOps & ProQA is one add-on at a flat ₹4,999 per month. It switches on five modules together: ProQA with its browser matrix, CI/CD pipelines and deployments, server provisioning and Git governance. The price does not grow with headcount, while the number of test jobs and runs you can start each month follows your plan. The add-on is listed with the others on the pricing page.
The modules share one workspace and the same user roles, but ProQA is not wired into the Infronest pipelines as an automatic deploy blocker. Your CI starts a test run through the webhook, and the release gate is a deliberate human sign-off. Teams that want a hard stop add a manual approval step to their own pipeline and look up the ProQA verdict before releasing.
Frequently asked questions
How much does ProQA cost?
Which browsers does ProQA test in?
Can ProQA test native mobile apps or real phones?
Do I have to write test scripts?
Can our CI pipeline trigger a test run?
How does the visual regression check work?
Is any test data sent to an AI service?
Can ProQA test pages behind a login or on a private network?
See also: CI/CD automation & deployments · Git governance · Server provisioning · VAPT platform · DevOps & ProQA pricing
Explore connected offerings
Give every release a verdict, not a hunch
Smoke, load, Lighthouse and security checks, Chromium screenshots against approved baselines, and a release gate someone signs. Book a walkthrough on your own staging URL.