Release Assurance
Focused functional, compatibility, integration, usability, accessibility, and regression testing for a defined release or feature set.
Outcome: clearer release risks, evidence, and decision support.
Development and Technology
Mobile App Testing Services for Confident, Reliable Releases
Rudrriv helps startups, product teams, ecommerce businesses, and enterprises test mobile applications across functionality, devices, operating systems, networks, usability, performance, security, and integrations. Engagements can support a single release, an automation programme, or ongoing quality assurance, with documented findings that help teams reduce avoidable release risk.
Request a ConsultationDevice and OS coverage planning
Documented quality-control workflows
Flexible project and managed models
Security-conscious test operations
Release Readiness WorkspaceTest cycle active
PlatformsiOS + Android
NetworksWi-Fi / 5G / 4G
Coverage overview
Core journeys92%
Device matrix78%
Regression pack84%
Accessibility checks71%
Illustrative interface and neutral example data; not client performance results.
Direct answer
What Are Mobile App Testing Services?
Mobile app testing services are structured quality-assurance activities used to evaluate whether an iOS, Android, cross-platform, or hybrid application works as intended across real user journeys, devices, operating systems, networks, integrations, accessibility needs, and performance conditions. Typical deliverables include a test strategy, coverage matrix, test cases, defect reports, evidence, regression results, and release-readiness summaries. Rudrriv can provide project-based, managed, or dedicated testing support. Results depend on clear requirements, stable environments, representative test data, and timely defect resolution by the product team.
Service we offer
A Practical Mobile Quality Plan Built Around Release Risk
Rudrriv structures testing around the application’s critical user journeys, technical architecture, release cadence, and commercial impact rather than applying the same checklist to every product.
Automation Enablement
Automation feasibility review, framework setup, priority-flow scripting, execution integration, maintenance guidance, and reporting.
Outcome: repeatable coverage for stable, high-value journeys.
Managed Mobile QA
Ongoing test planning, execution, defect triage, regression management, release reporting, and capacity aligned to the product roadmap.
Outcome: consistent testing support without building every role internally.
Key value propositions
What a Structured Testing Function Can Improve
The value of mobile testing comes from better visibility, repeatability, and release decision quality—not from claiming that software can be made defect-free.
Broader Coverage
Test priority devices, OS versions, screen sizes, networks, and integrations against a documented matrix.
Business outcome: fewer unexamined compatibility risks.
Clearer Quality Gates
Use severity criteria, retest rules, regression gates, and release summaries to support accountable decisions.
Business outcome: more consistent release governance.
Flexible Capacity
Add manual, automation, performance, or specialist testing capacity for launches, backlogs, or continuous delivery.
Business outcome: reduced pressure on product and engineering teams.
Measurable Visibility
Track coverage, pass rates, defect status, automation stability, and release risk using agreed reporting definitions.
Business outcome: better prioritisation and stakeholder communication.
Problems this service solves
Where Mobile Product Teams Commonly Lose Quality Control
Mobile quality problems often appear at the intersection of devices, environments, integrations, release pressure, and unclear ownership.
Problem
Inconsistent behaviour across devices
Features work in a developer environment but fail on specific operating-system versions, screen sizes, manufacturers, or network conditions.
Business impact
Support volume, poor ratings, abandoned journeys, and urgent hotfix work can increase.
How Rudrriv helps
Builds a risk-based device matrix and tests priority journeys across agreed real and cloud-hosted environments.
Problem
Regression risk grows with every release
New features repeatedly affect login, payments, notifications, search, account flows, or third-party integrations.
Business impact
Release confidence declines and engineering teams spend more time rechecking old functionality.
How Rudrriv helps
Creates a prioritised regression pack and identifies stable flows that may justify automation.
Problem
Defects are difficult to reproduce
Reports lack device details, build identifiers, test data, network conditions, logs, or evidence.
Business impact
Developers lose time, triage slows, and issues are reopened or disputed.
How Rudrriv helps
Uses defect templates, evidence standards, severity definitions, and retest records to improve clarity.
Problem
Testing is compressed at the end
Requirements, builds, credentials, or environments arrive late, leaving little time for risk-based testing.
Business impact
Coverage becomes uncertain and release decisions depend on incomplete information.
How Rudrriv helps
Moves test planning earlier, defines entry criteria, and aligns test cycles with the release workflow.
Who the service is for
Good Fit and Situations That Need a Different First Step
Mobile app testing works best when the product, environments, decision rights, and intended outcomes are sufficiently clear.
Good fit
- ✓Startups preparing an MVP, beta, investor demo, or public launch.
- ✓Product teams with frequent releases and growing regression scope.
- ✓Ecommerce, fintech, SaaS, logistics, healthcare, education, and professional-service apps with important customer journeys.
- ✓Enterprises seeking independent validation, broader device coverage, or managed QA capacity.
- ✓Agencies needing white-label or overflow testing support for client delivery.
May not be the right fit yet
- !The application concept or core requirements are still undefined; product discovery may be the better first step.
- !No stable build, test environment, credentials, or representative data can be provided.
- !The need is primarily code remediation, architecture redesign, or product management rather than independent testing.
- !The engagement requires formal certification, penetration testing, or licensed compliance advice beyond the agreed QA scope.
Common use cases
Mobile Testing Scopes for Different Product Stages
Scope should reflect product maturity, release risk, customer impact, and the cost of failure.
Startup launch readiness
- Situation
- First public release across iOS and Android.
- Recommended scope
- Critical-path functional, usability, compatibility, integration, and smoke regression testing.
- Deliverables
- Coverage matrix, defect log, evidence, and release-risk summary.
- KPIs
- Critical-flow coverage, pass rate, defect closure status.
Ecommerce conversion assurance
- Situation
- Frequent promotions, catalogue changes, and payment updates.
- Recommended scope
- Search, product, cart, checkout, payment, account, notification, and analytics validation.
- Deliverables
- Regression pack, device results, integration checks, and release report.
- KPIs
- Checkout pass rate, escaped defects, execution time.
Enterprise automation programme
- Situation
- Large repeatable regression workload across product squads.
- Recommended scope
- Automation feasibility, framework selection, priority scripting, pipeline integration, and maintenance.
- Deliverables
- Automation architecture, scripts, run reports, and operating documentation.
- KPIs
- Stable automated coverage, run reliability, maintenance effort.
Capabilities
Mobile App Testing Capabilities
Each capability can be combined into a release-specific or ongoing quality plan. Final scope depends on app architecture, risk, access, and environment readiness.
Functional and Journey Testing
Covers onboarding, authentication, search, forms, payments, notifications, account management, offline behaviour, deep links, and business rules.
- Inputs: requirements, user stories, acceptance criteria, builds, test data.
- Deliverables: test cases, execution evidence, defect reports, retest results.
- Dependencies: clear expected behaviour and stable test environments.
Compatibility and Device Coverage
Tests agreed device families, OS versions, screen sizes, orientations, permissions, interruptions, and network conditions.
- Inputs: audience analytics, support policy, market priorities.
- Deliverables: device matrix and compatibility findings.
- Exclusion: exhaustive testing of every device combination is rarely practical.
Performance and Reliability
Evaluates startup time, responsiveness, API behaviour, resource use, network degradation, concurrency, and stability using suitable tools and environments.
- Inputs: performance goals, architecture, test environment, monitoring access.
- Deliverables: scenarios, results, bottleneck observations, recommendations.
- Limitation: lab results may differ from production behaviour.
Usability and Accessibility
Reviews navigation clarity, touch targets, feedback states, content readability, error handling, screen-reader support, focus order, contrast, and orientation behaviour.
- Inputs: design files, personas, supported accessibility requirements.
- Deliverables: usability observations and accessibility issue log.
- Limitation: specialist certification may require an independent accredited audit.
API, Integration, and Data Testing
Checks mobile-to-backend flows, API responses, validation, session handling, analytics events, third-party SDKs, payments, maps, messaging, and identity services.
- Inputs: API documentation, sandbox access, schemas, test accounts.
- Deliverables: integration test evidence and data-quality findings.
- Dependencies: representative endpoints and controlled test data.
Automation and Continuous Testing
Prioritises stable, repeatable, high-value flows for automation and integrates execution into suitable CI/CD workflows.
- Inputs: source access where required, build process, test IDs, pipeline details.
- Deliverables: framework, scripts, run reports, maintenance guidance.
- Exclusion: automation does not replace exploratory, usability, or all manual testing.
Deliverables we offer
Decision-Ready Test Assets and Reporting
Deliverables are designed to help product, engineering, operations, and procurement teams understand coverage, findings, ownership, and release risk.
| Deliverable | What it includes | Format | Delivery stage | Client input required |
|---|---|---|---|---|
| Test strategy | Objectives, scope, risks, test types, environments, entry and exit criteria | Document or workspace page | Planning | Roadmap, architecture, priorities |
| Coverage matrix | Features, user journeys, devices, OS versions, networks, and integrations | Spreadsheet or test-management tool | Planning and execution | Audience and support policy |
| Test cases and charters | Repeatable steps, expected outcomes, data, and exploratory objectives | Test-management platform | Design | Requirements and acceptance criteria |
| Defect reports | Severity, reproduction steps, environment, evidence, logs, and status | Issue tracker | Execution | Triage owners and workflow |
| Regression results | Pass, fail, blocked, not-run status and retest evidence | Dashboard or report | Release validation | Release candidate and fixes |
| Release-readiness summary | Coverage, unresolved risk, limitations, and decision considerations | Executive summary | Release gate | Risk tolerance and decision owner |
| Automation assets | Framework, scripts, configuration, documentation, and run output | Repository and reports | Implementation and support | Access, coding standards, pipeline details |
Our process
How Rudrriv Delivers Mobile App Testing
The process establishes shared expectations, protects test quality, and keeps release decisions connected to evidence. Timing varies with scope, access, build stability, and defect resolution.
Discover
Confirm business goals, app architecture, release plan, users, risks, and constraints.
Output: discovery notes and information-gap list.Assess
Review requirements, environments, device needs, integrations, data, and existing assets.
Output: baseline assessment and risk priorities.Define Scope
Agree coverage, exclusions, roles, severity model, tools, and review gates.
Output: approved test plan and responsibility map.Prepare
Set up test environments, accounts, data, devices, test cases, and reporting workflows.
Output: ready-to-execute test pack.Execute
Run planned and exploratory tests, capture evidence, and log reproducible defects.
Output: execution results and defect records.Triage and Retest
Support severity review, verify fixes, update status, and identify regression impact.
Output: validated defect disposition.Regression and Gate
Recheck priority journeys and summarise residual risk against agreed exit criteria.
Output: release-readiness report.Improve
Review coverage gaps, recurring defects, automation opportunities, and process changes.
Output: improvement backlog and support plan.Technology and platform expertise
Tools Selected for Coverage, Maintainability, and Fit
Tool choices should follow the app stack, supported platforms, team capability, security policy, budget, and reporting needs. Listing a tool does not imply a certification or mandatory recommendation.
Mobile automation
Used for repeatable functional checks and continuous testing.
AppiumEspressoXCUITestMaestroDetox
Device and cloud labs
Support broader device, OS, and browser coverage when physical inventory is limited.
BrowserStackSauce LabsFirebase Test LabAWS Device Farm
API and network testing
Validate backend contracts, mobile requests, errors, latency, and integrations.
PostmanCharles ProxyProxymanREST Assured
Performance and reliability
Support response-time, load, concurrency, and resource investigations.
JMeterk6GatlingAndroid ProfilerInstruments
Test and defect management
Provide traceability, workflow, evidence, reporting, and stakeholder visibility.
JiraAzure DevOpsTestRailZephyrXray
CI/CD and collaboration
Connect automated checks and reports with the delivery workflow.
GitHub ActionsGitLab CIJenkinsBitriseSlack
Engagement models
Choose a Delivery Model That Matches Release Demand
Rudrriv can align team structure and billing with a defined release, changing backlog, ongoing product roadmap, or outsourced QA function.
| Model | Best for | Client involvement | Flexibility | Billing approach | Main advantage | Main limitation |
|---|---|---|---|---|---|---|
| Fixed-scope project | Defined release or assessment | Moderate | Low to medium | Milestone or project fee | Clear deliverables and boundaries | Changes require scope control |
| Time and materials | Changing backlog or investigation | Moderate to high | High | Actual approved effort | Adapts to evolving needs | Final cost depends on usage |
| Monthly managed service | Continuous releases and regression | Moderate | High within capacity | Monthly service fee | Consistent workflow and reporting | Requires operating rhythm and prioritisation |
| Dedicated specialist or team | Embedded product support | High | High | Monthly capacity | Continuity and product knowledge | Client must provide direction and access |
| White-label QA | Agencies and software partners | Moderate | Medium to high | Project or capacity based | Extends delivery capability | Branding, communication, and ownership must be clear |
Practical examples
Illustrative Ways the Service Can Be Applied
These examples show possible scope structures. They are not representations of named clients or guaranteed outcomes.
Example: Marketplace app release validation
Situation: A two-sided marketplace is releasing identity verification, chat, and payout changes. Scope: functional, integration, device, interruption, notification, and regression testing. Model: fixed-scope release project. Deliverables: journey coverage, defect evidence, retest status, and release-risk summary. Measurement: critical-flow pass status, unresolved severity, and coverage against the agreed matrix.
Example: Retail app managed regression
Situation: A retailer releases promotions and checkout changes every two weeks. Scope: recurring smoke, regression, analytics, payment, accessibility, and device checks. Model: monthly managed service. Deliverables: cycle reports, defect trends, release gates, and an evolving regression pack. Measurement: execution completion, defect reopen rate, escaped defects, and cycle predictability.
Example: SaaS mobile automation foundation
Situation: A B2B SaaS team has a growing manual regression burden. Scope: feasibility review, framework setup, priority-flow automation, CI integration, and handover. Model: time-and-materials implementation. Deliverables: scripts, repository, run reports, documentation, and maintenance backlog. Measurement: stable automated coverage and run reliability.
Relevant case-study patterns
Evidence Rudrriv Should Provide During Evaluation
Company-specific case studies and verified performance evidence should be reviewed during procurement. The following case-study structures show what useful evidence would contain.
High-frequency consumer app
Look for an example that documents supported platforms, release cadence, original coverage gap, team model, test process, deliverables, baseline, measured change, and client-approved outcomes.
Evidence required: approved client reference, dated metrics, scope boundaries, and methodology.
Regulated or sensitive-data application
Look for evidence of access controls, masked test data, environment separation, audit trails, specialist review boundaries, and issue-escalation procedures.
Evidence required: security review, contractual controls, and client-approved case details.
Expected outcomes and KPIs
Measure Coverage, Quality Risk, and Delivery Reliability
Useful metrics connect testing activity to release decisions. They should be defined consistently, based on a baseline, and interpreted alongside scope and product risk.
| KPI | What it measures | Baseline required | Reporting frequency | Important limitation |
|---|---|---|---|---|
| Critical-journey coverage | Planned priority flows with executed evidence | Agreed journey inventory | Per cycle or release | Coverage does not prove absence of defects |
| Pass, fail, and blocked rate | Current execution status | Stable test pack | Daily during active testing | Can be distorted by unstable environments |
| Defect leakage | Issues found after the agreed release gate | Historical release data | Per release or monthly | Depends on detection and classification consistency |
| Defect reopen rate | Fixes that fail verification or regress | Defect workflow history | Per cycle | May reflect unclear requirements as well as code quality |
| Automation stability | Reliable runs versus flaky or failed runs | Initial run history | Per pipeline and monthly | High pass rate can hide low coverage |
| Crash-free sessions | Production stability for observed users | Production analytics | Weekly or release based | Requires representative telemetry and consent controls |
| Response and startup time | Performance against agreed scenarios | Device and network baseline | Per major release | Lab conditions may not match every user environment |
| Release-risk status | Residual risk against exit criteria | Agreed severity and acceptance model | At release checkpoints | Final release decision remains with the client |
Actual outcomes depend on the starting position, available data, implementation quality, client participation, market conditions, technology constraints, and agreed service scope.
Pricing and cost factors
What Influences Mobile App Testing Cost
Rudrriv prepares estimates after reviewing the application, release objective, required test depth, platforms, environments, access, governance, and expected deliverables. No universal price reflects every mobile product.
Scope and complexity
Number of features, user roles, platforms, integrations, languages, workflows, and release candidates.
Coverage and environments
Device matrix, OS versions, real-device needs, network conditions, cloud-lab licensing, and test-data preparation.
Test depth
Manual, automation, performance, accessibility, security-support, API, analytics, and integration requirements.
Team structure
QA leadership, manual testers, automation engineers, performance specialists, security specialists, and coordination.
Delivery conditions
Release cadence, turnaround expectations, time-zone coverage, support hours, reporting frequency, and review gates.
Change and transition
Legacy assets, provider handover, framework repair, environment instability, scope changes, and migration needs.
Why consider Rudrriv
A Delivery Model Designed for Practical Quality Operations
Rudrriv’s value should be assessed through the proposed team, scope, controls, communication plan, evidence, and commercial terms—not generic claims.
01
Cross-functional delivery
Testing can be coordinated with development, data, automation, cloud, and business-support specialists where the agreed scope requires it.
Evidence to request: named roles, experience profiles, and responsibility matrix.
02
Flexible engagement options
Project, managed-service, dedicated-team, staff-augmentation, and white-label structures can match different product stages.
Evidence to request: proposed capacity, billing rules, and change-control terms.
03
Documented workflows
Planning, test evidence, defect quality, review gates, reporting, and escalation can be defined before execution begins.
Evidence to request: sample templates and quality-control process.
04
Scalable capacity
Testing capacity can be adjusted around launch windows, product backlogs, release peaks, and ongoing programmes subject to availability.
Evidence to request: staffing plan, backup coverage, and onboarding approach.
05
Transparent reporting
Status, coverage, blockers, defects, limitations, and residual risk can be reported using agreed definitions and stakeholder views.
Evidence to request: dashboard examples and reporting cadence.
06
Post-delivery support
Retesting, regression, automation maintenance, knowledge transfer, and operating documentation can be included when scoped.
Evidence to request: support windows, ownership, and exit plan.
Security, quality, and compliance
Controls for Testing Sensitive Applications and Data
Testing may involve source code, credentials, customer data, payment flows, employee records, health information, or other sensitive assets. Controls must be agreed with the client and matched to the application’s data classification and regulatory environment.
Access control
Role-based access, least privilege, multi-factor authentication, approved accounts, and timely access removal.
Credential handling
Secure sharing, environment separation, no credentials in defect screenshots, and rotation after engagement changes.
Data minimisation
Use synthetic or masked test data where possible, with controlled retention, transfer, and deletion procedures.
Quality traceability
Requirement links, reviewed test cases, evidence standards, severity criteria, retesting, and release-summary controls.
Audit and escalation
Activity records, defect history, approval checkpoints, incident escalation, and defined decision ownership.
Continuity and change control
Backup staffing, handover notes, version control, scope-change review, and service continuity planning.
Scope boundary: Rudrriv can provide administrative, operational, technical, and analytical testing support. Formal legal opinions, statutory certification, regulated sign-off, and licensed penetration-testing attestations remain with appropriately qualified client or third-party professionals unless expressly contracted and verified.
Recognition, technology ecosystems, and delivery experience
Mobile Testing Within a Broader Digital Delivery Environment
Mobile quality is connected to product design, APIs, cloud infrastructure, analytics, ecommerce, automation, customer support, and business operations. Rudrriv’s wider service model can support coordinated delivery where responsibilities, evidence, and specialist boundaries are clearly defined.
Rudrriv customer feedback
Customer Feedback on Mobile Quality Support
The following are illustrative testimonial examples written to show the type of service-specific feedback a mobile testing page may present. They are not represented as verified customer endorsements.
★★★★★
“The testing team gave us a clear device matrix, stronger defect evidence, and a practical release summary. The most useful improvement was the discipline around retesting and regression, which made conversations between product and engineering more focused.”
AK
Ananya KapoorHead of Product · Consumer Marketplace
★★★★★
“Our checkout changes needed coverage across payments, promotions, and analytics. The engagement created a repeatable regression pack and surfaced environment dependencies early enough for the team to act before the release gate.”
DM
Daniel MensahEcommerce Director · Retail
★★★★★
“Rudrriv helped us separate what should be automated from what still required exploratory testing. The resulting framework was easier for our internal engineers to understand and maintain than a large collection of brittle scripts.”
LC
Lucia ContiVP Engineering · B2B SaaS
★★★★★
“The team adapted to our agency workflow and produced client-ready evidence without overcomplicating communication. We valued the clear scope boundaries, predictable handoffs, and attention to device-specific issues.”
RM
Rafael MorenoDelivery Partner · Digital Agency
★★★★★
“The accessibility review identified practical issues in focus order, labels, error messaging, and touch targets. The findings were prioritised well, and the team was careful to distinguish usability observations from formal certification.”
SP
Sofia PetrovProgramme Lead · Education Technology
★★★★★
“We needed independent release assurance for a mobile workflow connected to several backend systems. The testers documented integration failures clearly and helped us track residual risk without making unrealistic claims about zero defects.”
JT
Jordan TaylorTechnology Operations Manager · Logistics
Frequently asked questions
Mobile App Testing Questions Buyers Commonly Ask
These answers cover scope, delivery, cost, ownership, security, transitions, and measurement. Contractual terms and final recommendations depend on the specific application and engagement.
What are mobile app testing services?
Mobile app testing services evaluate an application across functionality, devices, operating systems, networks, usability, accessibility, performance, security, integrations, and release readiness. The exact scope depends on the app architecture, supported platforms, risk profile, release cadence, and available test environments.
What is included in a mobile app testing engagement?
A typical engagement includes discovery, test planning, environment setup, test-case design, manual or automated execution, defect reporting, retesting, regression testing, and release-readiness reporting. Device-lab access, performance testing, security testing, and ongoing automation may be scoped separately.
Who should outsource mobile app testing?
Outsourcing can suit product teams that need broader device coverage, independent quality review, specialist test skills, or flexible capacity around releases. It may be less suitable when requirements are still undefined, no test environment exists, or sensitive systems cannot be accessed under an approved security model.
What deliverables do clients receive?
Deliverables commonly include a test strategy, coverage matrix, test cases, defect logs, evidence, regression results, device and operating-system coverage reports, risk summaries, and a release-readiness recommendation. Formats and documentation depth depend on governance and audit needs.
How does the mobile app testing process work?
The process moves from requirements and risk analysis to planning, setup, execution, defect triage, retesting, regression, and reporting. Review gates are agreed with the client so product owners, developers, and testers can make informed release decisions.
How long does mobile app testing take?
Timing depends on app size, feature complexity, platform coverage, test depth, integration count, environment readiness, defect volume, and release cadence. A focused release check may be shorter than a full baseline assessment or automation programme, so estimates follow scope review.
How is mobile app testing priced?
Pricing is normally based on scope, test types, device coverage, platforms, integrations, team composition, automation requirements, security controls, and reporting frequency. Fixed-scope, time-and-materials, managed-service, and dedicated-team models are common. Final estimates require requirements and access review.
What does the testing team look like?
A team may include a QA lead, manual testers, automation engineers, performance testers, security specialists, and project coordination. The mix depends on risk and complexity; specialist security or regulated-domain review may require a separately qualified provider.
Which mobile testing tools and platforms can be used?
Common options include Appium, Espresso, XCUITest, Selenium-based services, BrowserStack, Sauce Labs, Firebase Test Lab, Charles Proxy, Postman, JMeter, k6, Jira, and test-management platforms. Tool selection depends on architecture, budget, coverage, integrations, and team maintainability.
How will communication and reporting work?
Communication can include agreed stand-ups, defect triage, status summaries, release checkpoints, and dashboards. Reporting frequency should match release risk and client governance. Critical defects require a defined escalation path and client decision owner.
How is testing quality controlled?
Quality controls can include peer-reviewed test cases, traceability to requirements, reproducible defect evidence, severity criteria, independent retesting, regression gates, and test-summary reviews. These controls reduce ambiguity but cannot prove that software contains no defects.
How is app and customer data protected during testing?
Controls may include least-privilege access, multi-factor authentication, secure credential sharing, masked test data, approved devices, audit trails, retention limits, and access removal. The final control set depends on client policy, data classification, hosting, and applicable regulation.
Who owns the test assets and automation code?
Ownership should be defined in the statement of work. Clients commonly receive agreed test cases, reports, evidence, and automation assets after payment, subject to third-party licences and reusable framework components identified in the contract.
Can Rudrriv take over from another testing provider?
A transition is possible when existing documentation, environments, credentials, test assets, defect history, and responsibilities can be reviewed. A controlled handover normally includes an inventory, access validation, knowledge transfer, coverage-gap assessment, and transition plan.
How are mobile app testing results measured?
Measurement can include requirement coverage, pass rate, defect density, escaped defects, reopen rate, automation stability, execution time, device coverage, crash rate, response time, and release-risk status. Metrics require an agreed baseline and should be interpreted in context rather than used as guarantees.