Browser-based performance tests can now exclude failed transactions from report views, giving release owners a cleaner basis for judging successful user journeys without discarding failure evidence.
BlazeMeter 3.6 extends the existing failed-transaction exclusion capability from JMeter-based testing to browser-based performance tests. Teams can filter request statistics and timeline data to show passed transactions, or separate failed results by error code and failed assertion.
For release governance, this matters because a blended report can make it difficult to answer two different questions:
- Did the intended user journey meet its performance target?
- Did failures occur because of an application, assertion, test-data, or environment issue?
The new filtering helps teams present those answers separately. It should not be used to suppress failures from release evidence; instead, it creates a more disciplined review process where performance outcomes and test-execution failures are assessed on their own merits.
Useful control points include:
- Define which failure categories require remediation before release approval.
- Retain unfiltered reports alongside filtered views for auditability.
- Document the reason when a failed transaction is excluded from a release assessment.
- Align QA, engineering, and product owners on error-code versus assertion-failure handling.
More dependable AI Log Analysis for large Multi-Tests
AI Log Analysis now samples up to 20 random sessions per test within a Multi-Test. Previously, very large session counts could prevent the analysis from starting or completing. The new approach keeps the analysis available even when total test volume is substantial.
This reduces a common operational issue: diagnostic tooling becoming least available when test scale is highest. The sampled output provides a representative view that teams can use to identify likely fault patterns and focus deeper investigation.
Sampling does introduce an important governance consideration. AI findings should guide triage, not replace raw artifacts or detailed evidence for material release risks. Teams should keep logs, test reports, and environment context available when a production decision depends on the finding. The analysis is reliable at scale, but it is not a complete census of every session.
Pause API Monitoring alerts without pausing the tests
API Monitoring buckets can now pause notifications while tests continue running and recording results. The control applies across configured channels, including email, Slack, Microsoft Teams, and other integrations.
This is useful during planned maintenance, known third-party incidents, or approved change windows. Operations teams can avoid an alert flood without creating a monitoring blind spot. Results continue to show whether the service is recovering, degrading further, or behaving as expected.
The bucket dashboard displays a banner while notifications are paused, and a bucket-level API supports CI/CD or operational automation. This reduce the need for manual notification-rule changes during short-lived events.
For controlled use, enterprises should:
- Assign an owner and an expiry expectation to each notification pause.
- Record the maintenance or incident reference associated with the pause.
- Require a post-window review of recorded test results.
- Automate pause and resume actions where change workflows are already automated.
Faster, more consistent API test authoring
Default headers in API Monitoring now provide autocomplete suggestions for common HTTP header names. The behavior matches header entry on individual request steps, while still allowing any custom header name.
This is a small interface change with practical value. Standardized header names reduce avoidable configuration errors across shared environments and templates. Teams managing authentication, content negotiation, tenant routing, or trace headers can apply consistent conventions more easily.
AI Script Assistant also now generates native XML validation with XPath assertions when requests or responses use XML, including SOAP payloads. Rather than converting XML to JSON before validation, generated assertions evaluate the payload in its actual structure. JSON payload behavior remains unchanged.
For teams supporting older service contracts alongside newer APIs, native XML checks reduce the risk that generated tests validate an interpretation of the response rather than the response itself. Review generated assertions as part of normal test-code governance, especially where namespaces, optional nodes, or contract versions vary.
Governance implications for delivery leaders
BlazeMeter 3.6 provides more control over how evidence is filtered, analyzed, and communicated. The primary opportunity is not simply faster testing; it is a clearer distinction between operational exceptions, test failures, and verified application behavior.
Leaders should update working agreements for:
- Performance-report interpretation and release sign-off.
- Acceptable use of sampled AI analysis in incident and release workflows.
- Notification pause authorization, duration, and recovery checks.
- Review standards for AI-generated XML assertions.
These changes makes ownership more explicit across QA, SRE, platform, and application teams.
How Merito helps
Merito helps enterprises implement BlazeMeter capabilities within existing quality engineering, DevOps, and governance models. We can define performance evidence standards, automate monitoring exception workflows, review API test architecture, and establish controls for AI-assisted test generation.
The objective is practical: keep delivery teams moving while ensuring release decisions remain traceable, defensible, and based on the right evidence.
Merito is an authorized Perforce reseller and services partner. Our Perforce BlazeMeter team can scope licensing, sizing, and rollout for 3.6, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.
