Buddy Testing in Software Testing: Process, Benefits, and Best Practices
Most QA teams treat testing like a relay race, passing work from developer to tester and waiting for the report to come back. Buddy testing runs it differently. Two people from different roles, typically a developer and a tester, work through a feature together in real time. The developer explains how things work. The tester challenges assumptions and probes edge cases. Defects surface while the code is still warm and the context is still fresh. This guide covers what buddy testing is, when to use it, how to run it well, and where it falls short so your team can make an informed decision about where it fits.
Buddy testing pairs team members from different disciplines (typically a developer and tester) to evaluate features in real-time, enabling immediate feedback and fixes before formal testing cycles.
The process reduces defect escape rates by 20-35% for complex features and collapses traditional testing timelines from days to hours by enabling instant fix-verify-iterate cycles.
This collaborative approach works best for complex integrations, critical features, high-change areas, and compliance requirements, but may not justify the resource cost for simple CRUD operations or UI tweaks.
Effective buddy testing requires clear objectives, timeboxed sessions (60-90 minutes), real-time documentation, and complementary skill pairings to avoid becoming just another checkbox process.
Unlike pair testing (which typically involves two testers focusing on user perspective), buddy testing leverages the developer’s technical knowledge to debug issues immediately while transferring knowledge bidirectionally.
Tired of bugs making it to production because developers and testers work in silos? Buddy testing can cut defect rates by up to 35% while transforming quality from a handoff into a true partnership. Discover how to implement this technique without creating yet another process nobody wants to follow š
What Is Buddy Testing?
Buddy testing is a collaborative software testing technique where two team members from different disciplines evaluate a feature or module together. The classic pairing is a developer and a QA engineer, though it can also involve a designer, product owner, or business analyst depending on what is being tested and what perspectives are most valuable.
The developer brings deep technical knowledge about how the code actually works. The tester brings a critical eye for user experience, failure scenarios, and requirement gaps. This is not pair programming. You are not writing code together. One person, usually the developer, walks through the implementation while the other actively tests, asks questions, and challenges assumptions in real time.
What is buddy testing in practice? It is about collapsing the feedback loop between development and quality assurance. Instead of waiting for a formal test cycle, defects get flagged during or immediately after development. The tester gains context about technical constraints. The developer sees their work through a quality lens before it reaches the pipeline. Responsibilities split naturally: the developer explains functionality, reproduces issues on the fly, and provides instant context when something breaks. The tester designs test scenarios, documents findings, and verifies behaviour against requirements.
What sets buddy testing in software testing apart from other collaborative techniques is the cross-functional dynamic. When a tester asks why a button behaves differently on mobile, the developer might realize they missed a responsive design specification. When a developer explains database constraints, the tester adjusts their test data strategy. That knowledge transfer does not just improve the current feature. It makes both people sharper for the next sprint. Buddy testing meaning, at its core, is shared ownership of quality built directly into the development process rather than bolted on at the end.
In QA, collaboration is key, and buddy testing exemplifies this perfectly by pairing different perspectives to catch defects early. But what if you could take this approach even further with a platform designed to support and enhance these paired testing sessions? aqua cloud offers the ideal environment for buddy testing with its unified repository, where developers and testers can access, review, and update test cases in real-time. When practicing buddy testing, you can use aqua’s flexible project structures and real-time dashboards to maintain complete visibility across collaborative sessions. And now, with aqua’s domain-trained AI Copilot, your buddy testing becomes even more powerful, automatically generating comprehensive test cases based on your specific project documentation while you focus on creative edge cases that only human intuition can identify. The AI doesn’t just create generic tests; it understands your project’s language and context through RAG grounding technology, making every suggestion deeply relevant to your specific application.
Transform buddy testing from periodic collaboration to a continuous quality practice with aqua's intelligent test management.
Why Does Buddy Testing Matter in the Software Development Lifecycle?
Speed without collaboration produces chaos. Agile and DevOps methodologies demand rapid delivery, but compressed timelines often mean context gets lost between roles. A tester receives a ticket with minimal documentation, runs generic test cases, and misses the nuanced scenarios only the developer knows exist. Buddy testing solves this by embedding quality conversations directly into development. It is preventive rather than reactive, catching misunderstandings before they compound into production incidents.
The buddy check in software testing creates compounding value over time. Developers learn to think like testers, anticipating edge cases during coding rather than discovering them during review. Testers gain technical depth, crafting smarter test strategies based on actual implementation details rather than documentation that is often incomplete. That cross-pollination does not just improve individual features. It builds stronger teams. When a critical bug surfaces in production, the tester who buddy-tested that feature knows exactly where to look because they watched it being built.
Where buddy testing delivers the most visible value:
Complex integrations: When a payment gateway connects to multiple external APIs, having a developer and tester collaborate prevents misunderstanding of failure modes, timeout behaviours, and error handling expectations
New team members: Pairing a junior tester with a senior developer accelerates onboarding while ensuring features receive proper scrutiny from someone who knows the codebase
Critical features: Pre-release testing of authentication flows, data migrations, or financial calculations benefits from dual perspectives catching security gaps and edge cases before they reach production
Legacy code changes: When modifying systems with limited documentation, the developer’s historical knowledge combined with fresh testing eyes prevents regression surprises that written test cases alone would miss
High-ambiguity requirements: When specifications leave room for interpretation, real-time collaboration surfaces those ambiguities before implementation decisions become expensive to unwind
Consider how many times a bug has bounced between development and QA three times because reproduction steps were unclear or the context behind the failure was not captured in the ticket. Buddy testing short-circuits that waste. The tester sees the issue happen live, the developer understands the exact scenario, and the fix gets validated immediately rather than hours or days later.
What Are the Different Types of Buddy Testing?
Not all buddy testing looks the same. The technique adapts based on what you are testing, who is available, and what stage of development you are in. Understanding the variations helps you pick the right approach for your situation rather than applying a rigid one-size-fits-all process.
Developer-tester buddy testing is the classic pairing. A developer completes a feature, then works with a tester to walk through it. The tester drives the testing session while the developer observes, answers questions, and provides immediate context for unexpected behaviour. This works well for unit-to-integration level testing where technical depth matters. It typically happens during feature branch testing before merging, making it one of the earliest quality interventions in the development cycle.
Pair testing in agile shifts the dynamic. Two testers, or a tester and business analyst, collaborate to explore a feature together. One person executes tests while the other takes notes, suggests scenarios, and tracks observations. This approach works well for usability testing and requirements validation where dual perspectives on user experience matter more than technical implementation depth.
Exploratory testing management pairing takes a less scripted approach. A developer and tester actively hunt for unexpected behaviour without following a predefined test script. The tester probes creatively while the developer explains system boundaries and helps reproduce complex states. This works well during pre-release exploratory sessions or when testing unfamiliar territory like third-party integrations where the failure modes are not fully understood in advance.
Type
Typical Pairing
Best Use Case
Primary Focus
Developer-Tester
Dev + QA Engineer
Feature validation, technical testing
Catching implementation bugs early
Pair Testing
Tester + Tester or BA
Usability, requirements verification
User perspective and coverage
Exploratory Pairing
Dev + Tester
Pre-release, complex systems
Uncovering unexpected behaviours
Cross-functional
Dev + Designer or PO
UX-critical features, acceptance criteria
Requirements alignment and user flow
The type you choose depends on the immediate need. A backend feature with complex business logic calls for developer-tester buddy testing to avoid days of back-and-forth. Validating a new checkout flow against acceptance criteria suits pair testing with a business analyst. Investigating performance anomalies in a third-party integration calls for exploratory pairing. Matching the approach to the problem, rather than treating buddy test as a single rigid methodology, is what keeps it useful rather than bureaucratic.
When Should Buddy Testing Be Implemented?
Timing matters with buddy testing. The technique works best when complexity, risk, or knowledge gaps justify the investment of two people’s time simultaneously. You cannot buddy-test everything, and attempting to do so creates scheduling bottlenecks and diminishing returns. Use it strategically.
Complex systems with multiple moving parts are the clearest use case. A real-time notification system that touches WebSockets, database triggers, message queues, and push notification services is difficult to test in isolation. Without the developer present, a QA engineer might miss critical race conditions or architectural constraints that are invisible in the documentation but obvious once you understand the implementation. Buddy testing here means the developer can explain the event flow while the tester hammers edge cases like network interruptions or concurrent users.
New modules entering the codebase benefit from buddy testing as a knowledge-building exercise. When your team implements OAuth 2.0 for the first time, both the developer and tester are learning simultaneously. The tester’s questions during the session, “why does the redirect URI matter here?” or “what happens if the token expires mid-session?” produce answers that both people carry into future work. That shared learning compounds across sprints.
Tight deadlines create a counterintuitive use case. Rather than assuming everyone should work independently to maximize output, buddy testing can accelerate feedback loops. Instead of waiting for an async bug report, the developer gets immediate confirmation that a fix works. That rapid iteration beats traditional handoffs when every hour counts.
Scenarios where buddy testing is worth the investment:
Critical path features: Payment processing, authentication, data imports, anything that damages user trust or business operations when it fails
Cross-team dependencies: When a feature relies on another team’s API, buddy testing with a representative from that team catches integration mismatches before they reach staging
High-change areas: Refactoring legacy code where regression risk is high and only one person understands how the system behaves
Compliance requirements: Regulatory features benefit from dual verification to ensure nothing slips through documentation gaps
Proof-of-concept work: When exploring new technologies, pairing prevents wasted effort on approaches that are architecturally unworkable
Equally important is knowing when buddy testing does not make sense. Straightforward CRUD operations, minor UI copy changes, or well-documented API updates with comprehensive automated test coverage probably do not justify two people. If your QA team is already stretched across multiple workstreams, adding buddy testing to everything creates scheduling bottlenecks elsewhere. Selectivity is what keeps it valuable.
How Does the Buddy Testing Process Work?
Running an effective buddy testing session requires structure even when the dynamic stays informal. The framework keeps you productive without strangling the flexibility that makes collaboration valuable.
Step 1: Select your buddy and define objectives. Identify who brings complementary skills for this specific feature. A backend developer paired with a QA engineer who specializes in API testing makes sense for microservices work. A frontend developer paired with an accessibility-focused tester makes sense for UI features. Once paired, spend five minutes aligning on exactly what you are validating. Vague goals like “check if it works” waste time. Specific objectives like “verify user data persists after session timeout” or “confirm error messages match the design specification” keep the session focused.
Step 2: Plan the session logistics. Block 60 to 90 minutes. Shorter sessions work for narrow scopes, but complex features need room to explore. Decide upfront who is driving (usually the tester controls execution) and who is navigating (typically the developer explains implementation details and answers questions). Gather prerequisites before the session starts: test data, credentials, environment access, relevant tickets and specifications. Discovering you cannot access the staging environment 20 minutes into the session kills momentum and wastes both people’s time.
Step 3: Execute testing with active communication. The tester runs scenarios while verbalizing their reasoning: “I am trying to submit this form with a date in the past to see how validation handles it.” The developer jumps in with context: “That should trigger a client-side warning before hitting the API, but the API should also reject it as a second layer.” When something breaks unexpectedly, you debug in real time. The developer checks logs, explains expected versus actual behaviour, or pushes a quick fix. The tester documents observations, capturing not just defects but also UX friction, confusing error messages, and scenarios that need deeper exploration later.
Step 4: Review and document findings immediately. Do not wait until the next day to capture decisions. While the session is still live, decide what is a blocker, what is a nice-to-have, and what is working as designed. Create tickets for genuine issues with detailed reproduction steps while you can still demonstrate them. Note anything that surprised you, because surprises often indicate documentation gaps or assumption mismatches that will create problems again in future sprints.
Step 5: Follow up and close the loop. After the session, the developer addresses findings while the tester retests fixes. Schedule a brief follow-up for complex issues that required architectural changes. Update tickets, communicate status to the broader team, and spend five minutes reflecting on whether the session was productive and what could make the next one better. That retrospective discipline is what separates teams that get consistently better at buddy testing from teams that repeat the same inefficiencies.
Real sessions do not follow these steps linearly. You will bounce between them as questions arise or new scenarios emerge from unexpected behaviour. The framework keeps you honest without constraining the exploration that makes collaborative testing valuable.
What Are the Key Benefits of Buddy Testing?
Enhanced defect detection is the most measurable outcome. Two perspectives working simultaneously catch more than one perspective working sequentially. The developer identifies technical debt or performance implications the tester might not see in the output. The tester identifies user experience issues or requirement gaps the developer did not consider during implementation. Research on collaborative testing techniques suggests defect detection rates can improve by 20 to 35 percent compared to solo testing for complex features, because the combination of technical depth and testing perspective covers ground neither discipline reaches alone.
Faster feedback cycles compress the development timeline in ways that matter for team velocity. Traditional workflows mean a developer finishes code, QA tests two days later, bugs come back the day after, fixes land the following morning, retest happens a day after that. Buddy testing collapses that into hours. Fix, verify, and iterate in real time rather than through async ticket updates. That speed matters when you are shipping weekly or dealing with customer-critical issues on tight timelines.
Knowledge transfer happens as a natural byproduct rather than a scheduled event. The tester learns architectural constraints, build processes, and which parts of the codebase carry the most technical risk. The developer understands testing priorities, user workflows, and what makes features difficult to test after the fact. This cross-pollination makes both people more effective independently over time. Testers write better bug reports. Developers write more testable code. That compounding effect across sprints is one of the strongest arguments for making buddy testing a consistent practice rather than an ad hoc one.
Improved team dynamics address the us-versus-them friction that exists in many development and QA relationships. Buddy testing creates collaboration instead of a ticket-throwing dynamic where one team ships code and the other reports problems. Developers start treating quality as a shared responsibility. Testers gain enough technical context to engage as genuine partners rather than black-box validators. That psychological shift makes teams more willing to raise concerns early, ask questions that feel obvious, and surface uncertainty before it becomes a production problem.
Core benefits in summary:
Higher quality releases: Dual perspectives catch subtle issues like inconsistent error handling, edge case data failures, and accessibility problems that solo testing misses
Reduced rework: Catching defects during development prevents the expensive late-stage scrambles and emergency patches that follow production incidents
Better documentation: Real-time Q&A reveals documentation gaps that get addressed immediately rather than becoming confusion for the next developer who touches the feature
Skill development: Both roles develop competencies through direct exposure to the other discipline’s perspective and working methods
Faster onboarding: New team members paired with experienced colleagues in buddy testing sessions build product knowledge faster than any written documentation could provide
What Are the Disadvantages and Limitations of Buddy Testing?
Buddy testing requires two people’s time simultaneously. That cost is real. If your QA team is already stretched thin across multiple projects, pulling someone for 90-minute buddy sessions creates bottlenecks elsewhere. Finding overlapping availability between a developer mid-sprint and a tester managing a parallel regression cycle is not always straightforward. When scheduling becomes the primary obstacle, some of the speed benefits of the technique evaporate.
Personal dynamics can undermine effectiveness more than most teams anticipate. A junior tester paired with a developer who treats the session as an interruption will not speak up about concerns or push back on assumptions. A developer who views testing as not their responsibility will disengage. Buddy testing amplifies interpersonal dynamics rather than neutralizing them. Teams with communication problems or hierarchical friction between development and QA will find those problems surface quickly during collaborative sessions.
Scalability becomes a constraint as teams grow. Buddy testing every feature across a large development organization creates an impossible scheduling puzzle. The technique works best as a targeted tool applied to high-risk or high-complexity features rather than a default practice for every ticket. Teams that mandate it universally often find that engagement quality drops as it becomes an obligation rather than a deliberate choice.
Scope coverage limitations mean buddy testing does not replace your broader testing strategy. It excels at deep functional validation of specific features but does not provide comprehensive regression coverage or systematic performance validation. You still need automated tests, regression suites, and traditional testing practices operating in parallel.
Limitations worth tracking:
Resource intensity: Simultaneous time investment from two people compounds quickly across a sprint, particularly during crunch periods
Inconsistent quality: Effectiveness varies significantly based on participant engagement and skill levels, making outcomes harder to predict than structured testing approaches
Timezone friction: Distributed teams face real obstacles with synchronous collaboration, limiting buddy testing’s applicability for remote-first organizations working across multiple time zones
Documentation overhead: Real-time collaboration produces valuable insights that still need to be captured formally, adding a post-session task that can get deprioritized under deadline pressure
Dependency risk: If the developer is the only person who can provide technical context for a feature, their unavailability blocks follow-up validation on related issues
The limitations do not make buddy testing a poor choice. They make it a situational one. Understanding where it will not work prevents the mistake of forcing it into contexts where it creates overhead rather than value.
What Are the Best Practices for Effective Buddy Testing?
Define concrete objectives before the session starts. Do not walk into a room with “let’s test the thing.” Specify exactly what you are validating: the happy path checkout flow, edge cases around expired payment methods, and error message consistency across validation scenarios. Written objectives, even a quick bullet list, keep the session focused and give you a clear definition of done.
Protect the scheduled time. Block the calendar, close Slack, and treat the session as seriously as a sprint ceremony. Interruptions kill the flow and the shared context that makes collaboration productive. Timeboxing also matters. Ninety minutes is usually the effective ceiling before attention degrades. For narrower scopes, 60 minutes is often sufficient. Overlong sessions produce diminishing returns and create scheduling resistance for future sessions.
Match pairings to the testing context. Complementary skill sets matter more than availability. A tester who specializes in API testing paired with a backend developer is the right combination for microservices work. A frontend developer paired with an accessibility-focused tester is the right combination for UI work. Also consider interpersonal dynamics. Pairs that communicate well and respect each other’s expertise produce better outcomes than pairs assembled purely by schedule.
Document findings in real time using a shared tool. One person drives execution while the other logs observations. Capture reproduction steps immediately. Note behaviours that are not bugs but raise questions, because they often point to documentation gaps or future risk. Good real-time documentation means follow-up work is faster and the institutional knowledge from the session is preserved rather than fading within a day.
Balance structured coverage with exploratory probing. Start with critical happy paths to confirm the feature works as specified, then move into exploratory testing if time allows. A rough 60/40 split keeps you productive while leaving room for the unexpected discoveries that often produce the most valuable findings. Rabbit-holing into interesting edge cases before covering baseline scenarios is a common session failure mode.
Additional practices that improve outcomes over time:
Rotate pairings regularly: Avoid letting the same pairs own all buddy testing. Knowledge and testing perspective should spread across the team rather than concentrating in a few relationships
Debrief briefly after each session: Five minutes reviewing what worked and what did not produces compounding improvements over multiple sessions
Respect role boundaries: The tester leads testing strategy. The developer provides technical context. Clarity about who owns which decisions prevents sessions from becoming debates
Use sessions as teaching moments: Senior developers can explain implementation decisions, not just what the code does. Senior testers can demonstrate how to think about failure modes. That explicit knowledge transfer multiplies the value of each session beyond the immediate feature
Track outcomes to justify the practice: Defect escape rates for buddy-tested features versus non-buddy-tested features, or time-to-resolution for issues caught in sessions, give you data to evaluate whether the investment is paying off
How Does Buddy Testing Differ from Pair Testing?
The terms get used interchangeably, but the distinctions matter for choosing the right approach.
Moderate, focuses on user perspective and requirements
Problem-solving approach
Debug together, fix issues in real time
Document issues for later resolution
Knowledge transfer direction
Bidirectional between disciplines
Peer-to-peer within the same discipline
Session driver
Usually the tester, but flexible
Alternates between participants
The core distinction is who is pairing and why. Buddy testing specifically brings together different roles to combine technical depth with testing perspective. The developer can explain why a feature behaves a certain way, adjust code in the moment to test different scenarios, and provide immediate confirmation on whether something is a defect or working as designed. That real-time access to technical knowledge makes buddy testing particularly powerful for complex features where understanding the implementation helps design better tests.
Pair testing in agile typically pairs two people from the same or adjacent disciplines. The focus shifts to testing strategy, coverage, and user perspective. You are exploring user workflows and edge cases rather than interrogating implementation details. Pair testing works well when you need comprehensive requirement coverage or when fresh eyes on test design matter more than technical context.
Another practical difference is timing. Buddy testing often happens while code is still being written or immediately after development completes. The developer demonstrates work-in-progress functionality and the tester’s feedback influences completion. Pair testing typically happens after a feature is development complete, during formal testing phases where validation against acceptance criteria is the primary goal.
Both techniques share the core benefit of collaborative defect detection and both outperform solo testing for complex scenarios. The choice comes down to what kind of collaboration your current testing challenge actually needs.
How Does AI Fit Into Buddy Testing?
Testing buddy AI represents an emerging complement to human collaborative testing. AI-powered tools can work alongside a developer-tester pair, identifying patterns in test data, suggesting test cases based on code changes, and flagging areas where historical bug patterns suggest elevated risk. When integrated into a buddy testing workflow, an AI testing companion adds a data-driven layer to the human collaboration without replacing the judgment, creativity, and contextual knowledge that make the human pairing valuable.
Aqua cloud brings AI-assisted test generation and traceability into the collaborative testing workflow. aqua’s domain-trained AI Copilot can generate context-specific test cases aligned to requirements, surface coverage gaps, and maintain the audit trail that connects requirements to test results. That infrastructure supports buddy testing sessions by giving participants a structured starting point for test design and a system to capture findings in a format that persists beyond the session itself. The human collaboration handles the creative, contextual, and judgment-intensive work. The platform handles documentation, traceability, and test management at scale.
Implementing buddy testing effectively requires the right supporting tools. aqua cloud enhances collaborative testing practices with features specifically designed for teams working together on quality. With aqua’s unified test case repository, developers and testers can jointly review, execute, and document findings in real-time. You can eliminate the communication gaps that plague traditional handoffs. When you discover issues during buddy testing sessions, aqua Capture allows for visual bug reporting with screenshots and videos, making reproduction effortless and communication crystal clear. Most importantly, aqua’s domain-trained AI Copilot acts as your virtual third team member, generating project-specific test cases based on your own documentation and requirements. This RAG-grounded AI understands your application’s unique context, automatically identifying edge cases your buddy pairs might miss and saving up to 12 hours per week per QA engineer.
Save 97% of your testing time with buddy testing enhanced by AI that truly understands your project.
Buddy testing is not a universal solution. It demands time, coordination, and team dynamics that support genuine collaboration. Applied strategically to complex features, new modules, and high-risk changes, it delivers measurable improvements in defect detection and reduces the rework that follows production incidents. The entry point is simple. Block 90 minutes, pair a developer with a tester on a feature that carries real risk, and run through it together. The investment is small. The compounding value over sprints is not.
Buddy software testing is a collaborative technique where two team members from different roles, typically a developer and a QA engineer, work together to evaluate a feature or module in real time. The developer provides technical context about how the implementation works while the tester designs scenarios, challenges assumptions, and verifies behaviour against requirements. The buddy check in software testing collapses the feedback loop between development and quality assurance, surfacing defects while the code is still fresh and the context is immediately available rather than waiting for a formal handoff and test cycle. Buddy testing meaning, in practical terms, is shared ownership of quality embedded directly into the development process.
How can buddy testing improve collaboration between developers and testers?
Buddy testing breaks down the handoff dynamic that creates friction between development and QA teams. Instead of a developer shipping code and a tester reporting problems through a ticket system, both roles work toward the same outcome in the same session. The developer gains direct exposure to how testing decisions are made and what makes features difficult to validate. The tester gains technical context that improves test design and bug reporting quality. Over multiple sessions, that mutual understanding builds trust and reduces the miscommunication that produces bounced tickets, unclear reproduction steps, and repeated misalignment between what was built and what was expected. Teams that practice buddy testing regularly report stronger working relationships between development and QA because the collaboration replaces the adversarial dynamic that emerges when quality is treated as one team’s responsibility.
What are the best practices for implementing buddy testing in agile teams?
Start by applying buddy testing selectively to high-risk or high-complexity features rather than mandating it across every sprint task. Define concrete objectives before each session so both participants know what they are validating and what done looks like. Protect the scheduled time from interruptions and keep sessions timeboxed to 60 to 90 minutes to maintain focus and engagement. Match pairings based on complementary skill sets relevant to the feature being tested rather than scheduling convenience. Document findings in real time using a shared tool so institutional knowledge from the session is captured rather than lost. Rotate pairings regularly so technical and testing knowledge spreads across the team rather than concentrating in specific relationships. Debrief briefly after each session to identify what worked and adjust the approach for the next one. Finally, track outcomes such as defect escape rates for buddy-tested features to evaluate whether the investment is producing measurable quality improvements, which gives you the data to justify and refine the practice over time.
Home » Best practices » Buddy Testing in Software Testing: Process, Benefits, and Best Practices
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! š
