Your team is using Agile, but balancing QA validation with business value is still a nightmare? That’s easily one of the most frequent problems you might face when handling tests. As an outcome, there are many uncovered areas left in product releases. A quick boost to testing coverage can give Agile testing quadrants, which is a strategic framework for organizing testing activities. This post will guide you through the Agile testing quadrants and show how to implement them for optimal testing results.
Agile testing quadrants organize testing into four categories based on technology vs. business focus and team support vs. product critique purposes.
The framework was first sketched by Brian Marick in 2003 and later expanded by Lisa Crispin and Janet Gregory as a planning tool rather than a rigid taxonomy.
Implementation should start by mapping current testing activities to identify gaps, then gradually addressing the highest-risk areas across all four quadrants.
Many teams ship with solid unit tests, but have no idea if their system can handle traffic spikes or resist basic attacks. Discover how the Agile testing quadrants can boost your strategic quality planning approach👇
What is Testing Quadrant in Agile?
Agile testing quadrants are a planning framework that categorizes testing activities based on two key dimensions. The first is whether tests focus on technology or business concerns, and the second is whether they support team development or critique the product to uncover risks.
As you might already know, in Agile environments, testing is a continuous activity integrated throughout every sprint. This approach builds quality in from the start rather than inspecting at the end. The testing quadrants in Agile help your team organize their testing strategy by addressing fundamental questions about purpose and audience. Besides, they also clarify the timing of different test types throughout the development cycle.
The framework organizes testing into four categories:
Technology-facing tests verify internal code correctness and system behavior at the technical level
Business-facing tests validate that features deliver intended user value and meet stakeholder requirements
Tests that support the team provide fast feedback during development to guide implementation
Tests that critique the product reveal risks and limitations under real-world conditions
The quadrants don’t prescribe specific tests to run. Instead, they help your team evaluate whether you’re gathering appropriate evidence at the right times. This approach contrasts sharply with the agile vs traditional testing debate, where traditional methods often defer testing until later stages.
Key characteristics of the quadrants framework:
Planning tool, not taxonomy: The quadrants guide strategy rather than creating rigid test categories
Whole-team ownership: Testing becomes a collaborative responsibility across developers and testers. Product stakeholders also contribute to defining what quality means for each release.
Balance automation and exploration: Encourages both scripted checks and human investigation based on what each quadrant requires
Risk-based coverage: Helps teams identify gaps and prioritize testing effort based on feature risk profiles
The quadrants push you toward more strategic thinking about coverage and ownership. They make testing work visible and help your team understand what evidence you need to ship confidently.
When dealing with the complexities of Agile testing, having the right tools notable simplify the way your team balances those four quadrants. This is where aqua cloud, an AI-powered test and requirement management platform, can offer great value. The platform was designed specifically to support a comprehensive Agile testing approach across all quadrants. With aqua, your team can organize test scenarios that align with user stories and track coverage across business requirements. The unified repository keeps all test assets traceable and accessible to everyone on your team, whether supporting technical verification or business validation. What sets aqua apart is its domain-trained AI Copilot, which generates contextually relevant test cases directly from your requirements, chats, or even voice notes in seconds. This capability helps you shift left while maintaining comprehensive coverage. aqua integrates natively with Jira, Azure DevOps, Confluence, Jenkins, Selenium, and 12+ other automation frameworks, connecting seamlessly to your existing workflows and CI/CD pipelines.
Boost the value of your QA effort by 80% with aqua
The Agile testing quadrants emerged from the early Agile community’s need to integrate testing when the waterfall’s end-stage approach became obsolete. The framework evolved through contributions from testing thought leaders who recognized the need for a more structured approach to quality in iterative development.
2003: Brian Marick’s Original Matrix
Brian Marick came up with the Agile testing quadrant concept back around 2003. He made a key distinction between technology-focused checks and business-focused validation. He also separated tests that guide development from tests that critique the product. This framework filled a real gap because teams finally had a clear way to categorize and plan their testing efforts across different dimensions.
2009: Crispin and Gregory’s Expansion
Lisa Crispin and Janet Gregory transformed Marick’s concept into a widely-adopted framework through their book “Agile Testing: A Practical Guide for Testers and Agile Teams” published in 2009. They emphasized that the testing quadrants aren’t a maturity ladder where Quadrant 4 is somehow “better” than Quadrant 1. Rather, the real value lies in using the framework to identify testing gaps. Their work established the 4 quadrants of Agile testing as a standard reference point in Agile communities worldwide.
2014-Present: Current Adaptations
As DevOps and continuous delivery became standard, teams evolved the Agile Testing Quadrants to include shift-left testing, chaos engineering, and production monitoring. The model remains relevant because it adapts to new practices while preserving its core purpose: guiding balanced testing strategies. Today, teams use the SAFe Agile testing quadrants to figure out where AI-driven automation makes sense and where you really need human expertise. It’s especially helpful when you’re trying to balance Q1/Q2 automation with Q3 exploration and Q4 specialized testing.
The framework has endured over two decades because you face the timeless challenge of balancing different types of testing evidence. This evolution aligns with the rise of shift-left testing principles.
If I can avoid using a document that no one will really ever read, then I will do. I like to reference things like the Heuristic Testing Strategy Model by Bolton, Bach et al, as well as things like the Agile Testing Quadrants from Lisa Crispin.
Quadrant 1 focuses on automated unit tests and component checks. The quadrant also includes low-level integration work that gives immediate feedback when something breaks.
Primary characteristics:
Fast execution: Tests run in seconds, so you can iterate rapidly.
Developer-owned: Created and maintained by development teams who write code.
Granular verification: Validates individual functions and methods at the component level.
CI/CD integration: Runs automatically on every commit without manual intervention.
Refactoring safety: Gives you confidence when restructuring code or changing internal implementations.
Common test types:
Unit tests for business logic and domain rules
Component integration tests
API contract tests
Database migration validation
These tests are perfect for continuous testing and form the foundation of technical quality assurance. However, high code coverage doesn’t guarantee the product meets user needs. Q1 tests verify internal correctness but don’t validate whether the product works from a user’s perspective. They also can’t assess whether the system handles production-scale data effectively.
Key limitation: Q1 won’t catch emergent behavior that only appears when components interact or under real-world conditions with actual user data patterns.
Quadrant 2: Business-Facing, Supports the Team
Quadrant 2 translates stakeholder intent into executable examples that clarify what “done” means before coding starts. These acceptance-level tests bridge the gap between business requirements and technical implementation.
Primary characteristics:
Collaboration-driven: Created through Three Amigos sessions with developers and testers. Product owners also participate to ensure business alignment.
Business language: Written in domain terms like “customer,” “order,” or “payment” rather than technical implementation details like “database transaction” or “API call”
Current documentation: Serves as up-to-date specification of system behavior that stays synchronized with the actual codebase
Early clarification: Uncovers assumptions and edge cases before development starts. This reduces costly rework later in the sprint.
Automated validation: Runs regularly to verify business rules stay intact across code changes
Common test types:
Acceptance tests using Given/When/Then scenarios in tools like Cucumber or SpecFlow
API-level behavior verification
Business rule validation
Story-level functional tests
In healthy Agile setups, Q2 tests show how your system behaves in real business terms. The sweet spot is API-level acceptance testing. It runs fast enough to keep your CI pipeline humming, but it’s still clear enough that non-developers can actually understand what’s being tested. This is where Agile testing really delivers on that “whole-team quality” promise. Everyone can see the requirements in action and know exactly what’s being validated.
Key limitation: If tied too tightly to UI elements like specific button IDs or CSS selectors, tests become brittle and slow. They break with every interface change, even when underlying behavior stays correct.
Quadrant 3: Business-Facing, Critiques the Product
Quadrant 3 emphasizes discovery through human investigation of how the product works in real-world scenarios. This manual testing approach finds issues that automated checks consistently miss.
Primary characteristics:
Human-driven: Needs curiosity and creativity from experienced testers. Domain knowledge about the business context also proves essential.
Discovery-focused: Hunting for unknown issues like confusing workflows or inconsistent behavior rather than verifying known requirements
Learning exercise: Each session reveals new insights about product behavior under different conditions
User perspective: Evaluates workflow efficiency and usability from an end-user standpoint. Accessibility concerns also get addressed here.
Exploratory approach: Guided by test charters that define focus areas rather than rigid step-by-step scripts
Common test types:
Exploratory testing with specific charters defining scope and objectives
Usability sessions with target users
User acceptance testing conducted by actual stakeholders
Accessibility evaluation for WCAG compliance
Stakeholder demo feedback sessions
This quadrant gets neglected when your team leans too heavily on automation. Q3 really shines when you run exploratory charters like “what happens when the network drops?” or “how does a first-time user experience onboarding?” What you discover feeds right back into your backlog as new stories or acceptance criteria. Plus, you’ll get a much better sense of what your users actually need, which helps you plan smarter in future sprints.
Key limitation: Doesn’t scale like automated tests since each execution requires human judgment. However, the value comes from learning something new in each session rather than repeating the same checks.
Quadrant 4: Technology-Facing, Critiques the Product
Quadrant 4 validates whether the system can survive production realities through non-functional testing. This includes performance characteristics and security vulnerabilities that only appear under stress.
Primary characteristics:
Specialized skills: Often needs performance engineers who understand load patterns. Security experts and SREs also contribute their domain expertise.
Production-like conditions: Tests run against realistic environments that mirror actual infrastructure. Data patterns also match production volumes and distributions.
Non-functional focus: Evaluates scalability under increasing load and security against known attack vectors
Risk mitigation: Prevents incidents that damage reputation and cause financial losses
DevOps integration: Connects to observability platforms for metrics collection. Chaos engineering and synthetic monitoring also fall under this quadrant.
Common test types:
Performance and load testing to measure response times under concurrent users
Security vulnerability scanning for OWASP Top 10 issues
Disaster recovery validation to verify backup and restore procedures
Compatibility testing across browsers, devices, and operating systems
Reliability and chaos experiments like network partitions or service failures
Many teams defer Q4 until right before launch, discovering too late that APIs can’t handle peak load. Backup scripts might also fail when actually needed. The smarter approach is defining non-functional requirements like SLOs and performance budgets upfront. You then add Q4 evidence to your definition of done from the start.
Key limitation: Needs complex environments that replicate production infrastructure and specialized expertise to interpret results. However, waiting until the end invites catastrophic failures that could have been prevented with earlier testing.
Importance of Agile Testing Quadrants
Understanding what Agile testing quadrants are and why they matter is important because they push you to think about coverage. The framework goes beyond “we ran all the tests, and they passed” to examine whether you have the right evidence. The framework provides strategic value that directly impacts product quality and team collaboration. Business outcomes also improve when you apply the quadrants systematically.
Key reasons to use Agile testing quadrants:
1. Prevents Lopsided Testing Coverage
Without the quadrants framework, your team typically over-invests in comfortable areas while neglecting others. A development-heavy team might have excellent Q1 unit tests but zero Q3 exploratory testing. Q4 performance validation might also be completely absent. The quadrants make these gaps visible, helping your team evaluate whether you’re getting the right kinds of evidence to ship confidently.
2. Aligns Testing with Agile Values
The Agile testing quadrants concept naturally promotes core Agile principles. Q2 and Q3 need cross-functional conversations that break down silos between roles. Meanwhile, Q1 and Q2 run fast and often to provide rapid feedback. Q4 prevents burnout from firefighting production incidents that erode team morale. The framework makes testing work visible and helps your team balance automation with human investigation.
3. Enables Risk-Based Test Prioritization
Not every feature needs deep investment across all four quadrants of Agile testing. The framework helps your team scale testing effort based on actual risk levels rather than applying uniform coverage. A payment gateway demands heavy Q4 security and performance work because failures have serious consequences. Meanwhile, a simple UI tweak might only need Q1 and Q2 coverage. The quadrants support intelligent resource allocation based on business impact.
4. Improves Cross-Team Communication
The quadrants give you shared vocabulary that transcends role boundaries and eliminates ambiguity in planning discussions. Instead of debating whether to “shift left” or “automate everything,” your team can ask specific questions like “Are we missing Q3 investigation?” These concrete questions make planning conversations more productive. They also help you identify which expertise is needed for each story.
5. Surfaces Process Bottlenecks Early
When Q4 work gets consistently deferred, or Q3 findings never make it into the backlog, the framework surfaces these issues clearly. The quadrants act as a diagnostic tool for spotting where testing becomes a bottleneck. They also reveal where quality practices need strengthening before problems escalate.
Scenarios you might face:
Fintech Application: You’re building a money transfer feature. You use Q1 for fee calculation logic and currency conversion rules. Q2 covers transaction ledger acceptance scenarios, while Q3 explores edge cases like missing recipients or invalid account numbers. Q4 includes load testing for peak transaction volumes and security reviews for PII exposure risks.
E-commerce Platform: You’re building a money transfer feature. You use Q1 for fee calculation logic and currency conversion rules. Q2 covers transaction ledger acceptance scenarios, while Q3 explores edge cases like missing recipients or invalid account numbers. Q4 includes load testing for peak transaction volumes and security reviews for PII exposure risks.
SaaS Platform: After production incidents, you map your tests and find heavy Q1/Q2 coverage but missing Q3/Q4 work. You catch usability issues pre-launch by adding exploratory testing sessions. You also prevent outages by discovering that your database failover process doesn’t work as documented.
How to Implement the Testing Quadrants in Agile Environment
Implementing the testing quadrants in Agile isn’t about reorganizing your entire test suite overnight. You’ll want to start small, map what you’re already doing, and then fill gaps intentionally. Here’s a structured approach to adoption:
Step 1: Map Your Current Testing Activities
Categorize all existing testing practices by quadrant to reveal your testing profile. This assessment also identifies significant gaps in coverage.
Input:
List of all current testing activities: unit tests, acceptance tests, exploratory sessions, performance checks, security scans
Information about who owns each testing activity and which team members have expertise
Frequency and timing of each test type throughout the sprint cycle
Output:
Visual representation of tests mapped to each quadrant, typically as a 2×2 grid
Clear identification of well-covered versus empty quadrants
Baseline assessment of your team’s testing profile showing investment distribution
Create a matrix showing which quadrants have good coverage and which sit empty. Document honestly without judgment. Most teams discover they’re heavily invested in Q1 and partially in Q2. Meanwhile, Q3 and Q4 often get largely neglected due to time pressures or lack of specialized skills.
Step 2: Identify Your Highest-Risks
Prioritize gaps based on business impact to focus effort where you need it most. This analysis also helps you justify the testing investment to stakeholders.
Input:
Backlog of upcoming features with their associated risk profiles and business value
Recent production incident reports showing patterns of failure
Customer feedback and support tickets highlighting pain points
Business-critical functionality areas that handle sensitive data or revenue
Output:
Ranked list of quadrant gaps by risk level and potential business impact
Specific justification for prioritization tied to business objectives
Target quadrant for immediate attention with rationale
Analyze which missing quadrants pose the greatest risk to your product success. Multiple performance outages indicate Q4 priority for load testing. Consistent user confusion in support tickets signals Q3 need for usability testing. Vague acceptance criteria causing rework means strengthening Q2 with better examples.
Step 3: Define Quadrant-Specific Goals
Set concrete, measurable objectives aligned with identified risks. These goals also provide clear success criteria for retrospectives.
Input:
Prioritized list of gaps from Step 2 with business justification
Team capacity and skill assessment showing available expertise
Current sprint velocity and commitment levels to gauge realistic goals
Output:
Specific, measurable goals for each relevant quadrant with completion criteria
Definition of success criteria that stakeholders can verify
Timeline for achieving objectives broken down by sprint
Examples: “Add Q2 example workshops to every story kickoff” or “Conduct one Q3 exploratory charter per sprint with documented findings.” You might also set “Define SLOs and add Q4 smoke tests to CI/CD pipeline.” Another option is “Achieve 80% Q1 unit test coverage for business logic modules.”
Step 4: Integrate Quadrants into Sprint Planning
Make quadrant-based thinking part of your definition of done. This integration also affects your estimation process and capacity planning.
Input:
User stories with acceptance criteria and business value
Risk assessment for each story based on complexity and business impact
Team capacity for testing activities across all skill levels
Output:
Stories tagged with required quadrant coverage documented in acceptance criteria
Clear testing responsibilities assigned to specific team members
Updated definition of done including quadrant requirements for each story type
During story estimation, explicitly ask: “What evidence do we need across the quadrants to ship this confidently?” Stories touching critical business rules need Q1 and Q2 work. New user-facing flows call for Q2 and Q3 validation. High-traffic or payment features demand Q4 security and performance testing before release.
Step 5: Start Small and Iterate
Make incremental improvements each iteration rather than attempting comprehensive coverage immediately. This gradual approach also reduces the disruption to your existing workflow.
Input:
Results from previous steps showing initial progress
Retrospective feedback on testing effectiveness and team satisfaction
Metrics on defect escape rates and production incidents over the past few sprints
Output:
Incremental testing improvements each sprint with measurable progress
Refinements to quadrant coverage based on learning and feedback
Updated approach based on what’s working and what needs adjustment
Don’t try to complete all four quadrants in a single sprint. If Q3 is missing, start with one 30-minute exploratory session per sprint focused on high-risk features. If Q4 sits empty, pick one or two critical non-functional requirements like API response time and add basic checks. Review quadrant coverage during retrospectives and adjust based on what you learn. For implementing these strategies effectively, consider leveraging tools for agile testing that support comprehensive coverage across all quadrants.
Step 6: Foster Cross-Functional Collaboration
Build whole-team ownership by involving all roles in quadrant-specific activities. This collaboration also improves knowledge sharing across the team.
Input:
Current team structure and role definitions showing who does what
Skill matrix showing testing capabilities and areas for growth
Communication patterns and collaboration practices that work well
Output:
Cross-functional participation in all quadrants with no silos
Shared understanding of testing responsibilities across the team
Testing as a team conversation rather than isolated activity confined to QA
Encourage developers to participate in Q3 exploratory sessions to understand user pain points better. Involve product owners in defining Q2 acceptance criteria so requirements stay grounded in reality. Have testers contribute to Q1 test design to catch edge cases developers might miss. Use the quadrants as a communication framework during standups and planning sessions. They also work well in retrospectives to maintain shared context.
We use the quadrants to organize and be aware of the types of testing that needs to be considered during our iterations. But I must say, in my current org, not always by choice, but due to resource constraints, some Q4 activities (primarily, load and performance) do get carried out by shared resources in a sequential fashion.
Main Advantages of Using the Agile Testing Quadrants Model
The Agile testing quadrants concept delivers tangible benefits that improve testing effectiveness and product quality. Here are the key advantages:
1. Decision-Making Framework Over Reactive Testing
The quadrants give you a shared mental model that shifts testing from reactive checklists into strategic activities. Your team can focus conversations on evidence gaps rather than tool debates. Everyone understands what testing is happening and why that matters.
2. Test Coverage Beyond Code Metrics
Traditional coverage measures lines of code hit by tests, which feels shallow. The quadrants reframe coverage as credible evidence for the risks you care about. This includes correctness in Q1/Q2, user value in Q2/Q3, and system resilience in Q4.
3. Balanced Automation and Human Insight
The framework guides your team toward appropriate automation strategies. Q1 and Q2 tests run frequently in CI/CD pipelines. Q3 needs human curiosity that automation can’t replace. Q4 calls for specialized tooling with strategic interpretation.
4. Risk-Based Resource Allocation
The quadrants let your team tailor testing effort to feature-specific risks. A simple UI change might only need Q1 and Q2 validation. Payment gateways demand comprehensive Q4 security and performance testing.
5. Improved Cross-Functional Collaboration
The quadrants clarify which roles contribute to each testing type. Developers excel at Q1 unit testing. The whole team collaborates on Q2 acceptance criteria. Testers and users drive Q3 exploratory work. Specialists handle Q4 performance and security.
Aspect
Without Quadrants
With Quadrants
Testing Strategy
Reactive, checklist-driven, tool-focused
Proactive, risk-based, purpose-driven
Coverage Understanding
Code coverage percentage (shallow metric)
Evidence across correctness, user value, and resilience
Team Collaboration
Testing often isolated to QA role
Whole-team ownership with clear contribution areas
Automation Approach
All-or-nothing: either automate everything or nothing
Strategic automation based on quadrant characteristics
Risk Management
One-size-fits-all testing regardless of feature risk
Scaled effort based on specific risk profiles
Gap Identification
Blind spots discovered only in production
Systematic gap analysis during planning
Communication
Debates about “shift-left” vs “more automation”
Focused conversations about specific evidence needs
Bottleneck Detection
Process problems emerge through incidents
Early visibility into systemic testing issues
Resource Allocation
Equal effort across all features
Optimized investment where risk is highest
Quality Ownership
“Testing is QA’s responsibility”
Shared accountability across roles
The quadrants shift testing from an isolated quality gate into a strategic practice embedded throughout development. Your team moves from tool debates to focused conversations about evidence for specific features. This change leads to better resource allocation and earlier defect detection. Collaboration strengthens when everyone understands their role. You deliver higher-quality software that meets both technical and business requirements. The framework doesn’t add more testing work. Rather, you get the right testing happening at the right time by the right people.
Implementing the Agile testing quadrants calls for balance across technical validation and business acceptance. But without the right tools, this approach can become fragmented or even simply be unattainable. aqua cloud, an AI-powered test and requirement management solution, offers a unified solution that elegantly supports all four quadrants in one platform. From automated unit test integration in Q1 to comprehensive requirements traceability in Q2, exploratory testing capabilities in Q3, and performance metric tracking in Q4, aqua brings everything together under a single pane of glass. The platform’s AI Copilot, powered by domain-specific RAG technology, accelerates test creation while simultaneously lowering the technical barrier. Teams using aqua report achieving 100% requirement coverage while dramatically reducing the time spent on test management overhead. With integrations for Jira, Azure DevOps, Jenkins, Selenium, Ranorex, and 12+ other tools from your existing tech stack, aqua cloud is a safe solution to your testing needs.
Achieve 97% faster test creation with balanced quadrant coverage
The Agile testing quadrants serve as a strategic planning tool rather than a rigid prescription you must follow exactly. By organizing testing activities along business versus technology and support versus critique dimensions, the framework helps your team achieve balanced coverage. You can also identify blind spots before they become production incidents that affect users. Whether you’re writing unit tests or running exploratory sessions, the quadrants give you shared language for making quality a whole-team conversation.
The Agile testing quadrants are a framework that organizes testing activities into four categories based on two dimensions: technology-facing versus business-facing tests, and tests that support the team versus tests that critique the product. This model helps teams plan balanced testing coverage across different purposes and ensures both functional correctness and non-functional requirements get appropriate attention.
How do the four Agile Testing Quadrants differ from each other?
Quadrant 1 covers unit and component tests that verify technical correctness at the code level. Quadrant 2 focuses on acceptance tests that validate business requirements through executable examples. Quadrant 3 involves exploratory and usability testing to discover issues from a user perspective through manual investigation. Quadrant 4 addresses non-functional concerns like performance under load and security vulnerabilities. Reliability under production conditions also gets validated here.
How can teams apply Agile Testing Quadrants in real-world Agile projects?
Teams map existing tests to find coverage gaps across the four quadrants and integrate quadrant-based planning into sprints and estimation. During story estimation, they identify which quadrants apply based on risk, add Q2 example workshops for clarity, schedule Q3 exploratory testing each sprint, and require Q4 evidence in the definition of done for high-risk features.
What is the relationship between Agile Testing Quadrants and test automation strategies?
The quadrants guide automation by showing which tests benefit most. Q1 and Q2 are highly automatable and suited for frequent CI/CD runs, while Q3 relies on human exploration. Q4 uses specialized automation for performance and security testing but requires expert analysis. This balance avoids over-automation of exploratory work and under-automation of repetitive checks.
Home » Best practices » Agile Testing Quadrants: What is It & How to Use?
Do you love testing as we do?
Join our community of enthusiastic experts! Get new posts from the aqua blog directly in your inbox. QA trends, community discussion overviews, insightful tips — you’ll love it!
We're committed to your privacy. Aqua uses the information you provide to us to contact you about our relevant content, products, and services. You may unsubscribe from these communications at any time. For more information, check out our Privacy policy.
X
🤖 Exciting new updates to aqua AI Assistant are now available! 🎉
We use cookies and third-party services that store or retrieve information on the end device of our visitors. This data is processed and used to optimize our website and continuously improve it. We require your consent fro the storage, retrieval, and processing of this data. You can revoke your consent at any time by clicking on a link in the bottom section of our website.
For more information, please see our Privacy Policy.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Bankingaqua ALM helps banks increase testing productivity by over 50%
