Kindlebit
Product Engineering and QAPublicly listed capability

Find the broken journeys, edge cases and ambiguous requirements before your customers do.

Our testers explore your product with intent, test across browsers and devices, challenge unclear requirements and support business acceptance, with defects reported so developers can fix them the first time.

Book an exploratory test sessionSee how a session works

Kindlebit publicly lists this capability on its website or a third party profile. Named, approved project evidence is being compiled and will be added when Kindlebit confirms it.

Manual testing flow

  1. Requirements review
  2. Test design
  3. Exploratory sessions
  4. Compatibility
  5. Defect report
  6. UAT support

Reference design. Components are options, not a statement of what is deployed at any customer.

Problems this service is built to solve

These are situations we expect buyers to recognise. Each one states why it happens, what it costs and how we would approach it.

Broken user journeys

A user adds a coupon, changes quantity, then goes back and applies a second coupon. The total goes negative. Each feature passes its own test.

Why it happens
Tests follow single feature scripts and not realistic combinations of actions.
What it costs
Revenue loss and support cases from customers who found the combination.
How we approach it
We design scenario based tests around real user journeys and combinations, and run exploratory sessions with charters targeted at risky interactions.
What to measure
Journey coverage, defects found per session and escaped journey defects.

Unexpected edge cases

A name with an apostrophe or a very long address crashes an export. A date in another time zone appears a day early on an invoice.

Why it happens
Developers and testers share assumptions about typical data.
What it costs
Intermittent defects that are hard to reproduce and affect real customers.
How we approach it
We apply boundary, equivalence, localisation and data variety techniques, and use heuristics and checklists to push beyond the happy path.
What to measure
Edge case defects found before release and recurring data related incidents.

Browser and device inconsistencies

A form works in Chrome but the date picker fails on an older Safari. Mobile users on small screens cannot reach the submit button.

Why it happens
The team uses one browser and device, and no matrix exists.
What it costs
A share of users cannot complete tasks, and nobody knows how many.
How we approach it
We define a compatibility matrix from your analytics, test on real devices and browsers and report issues with screenshots and environment details.
What to measure
Coverage of the top browsers and devices by traffic, and compatibility defects in production.

Ambiguous business requirements

The requirement says 'the system should send a reminder before the deadline'. Developers, testers and the business each assume a different timing and channel.

Why it happens
Requirements are written without examples or acceptance criteria.
What it costs
Rework when the delivered feature does not match the expectation.
How we approach it
We review requirements before development, ask the questions that expose ambiguity and write acceptance criteria with examples agreed by the business.
What to measure
Defects traced to requirement issues and the number of clarified requirements before build.

Solutions we engineer

Concrete capabilities, each with the need it serves, how it integrates, what you receive and the value to expect.

Exploratory testing

Chartered sessions with notes, risk focus and debriefs, using heuristics and tours.

Customer need
Discover unknown problems.
Integration
Your build and environments.
Deliverable
Session reports and defects.
Business value
Finds what scripts do not.

Functional and system testing

Test design with equivalence classes, boundaries and state transitions, and traceability to requirements.

Customer need
Verify that features meet requirements.
Integration
Test management tools.
Deliverable
Test cases and results.
Business value
Verified behaviour.

Compatibility testing

Browser, OS and device matrix based on analytics, using real devices and device clouds.

Customer need
Work for the users you actually have.
Integration
BrowserStack, Sauce Labs or lab devices.
Deliverable
Compatibility report.
Business value
Fewer environment specific defects.

Usability and accessibility checks

Heuristic review, task walkthroughs and accessibility checks with assistive technology against WCAG 2.2.

Customer need
Find friction and barriers.
Integration
Design and development.
Deliverable
Usability and accessibility findings.
Business value
Better experience and compliance.

User acceptance testing support

Scenario preparation, tester coaching, defect triage and sign off tracking.

Customer need
Help the business sign off confidently.
Integration
Business teams.
Deliverable
UAT plan and results.
Business value
Shared confidence at release.

Requirements review

Reading requirements and designs for gaps, contradictions and testability.

Customer need
Prevent defects.
Integration
Product and engineering.
Deliverable
Review notes and acceptance criteria.
Business value
Less rework.

Defect reporting and triage

Reproducible reports with steps, evidence and impact, and triage with developers.

Customer need
Make fixes fast.
Integration
Jira, Azure DevOps or GitHub Issues.
Deliverable
Clear defect backlog.
Business value
Faster fixes.

How we solve it

A delivery sequence built around coverage, execution, defect analysis and release criteria.

Understand product and risks

Learn the product, users and past defects, and agree the areas of highest risk.

Review requirements

Read requirements and designs, list questions and write acceptance criteria with the team.

Plan coverage

Define charters, scenarios, data and the compatibility matrix.

Execute tests

Run scripted and exploratory sessions, recording evidence and observations.

Report and triage defects

Log reproducible defects with severity and impact, and triage them with developers and product owners.

Verify fixes and regress

Retest fixes, check related areas and update test cases.

Support acceptance

Prepare UAT, coach business testers and track sign off.

Feed learning back

Identify automation candidates and recurring defect patterns and share them with the team.

Solution in action: Exploratory testing of a quote and checkout flow

Reference Architecture An illustrative scenario. It describes how we would structure the work, not a delivered customer project.

Starting problem

A new quoting feature is about to be released and the team has only tested the happy path.

Existing workflow

Developers test their own work and a short checklist covers the main path.

Improved workflow

A tester runs charters on pricing combinations, discounts, partial saves, session timeouts, back button use and different locales across the browser matrix. Defects are reported with screenshots, and the requirement gaps found are resolved with the product owner.

A feature is ready for test.

Systems involved

Application under test, staging environment, device cloud, defect tracker.

Data movement

Synthetic customers, products and price lists with edge values.

Human decisions

Testers explore and judge. Product owner decides on requirement clarifications.

Automation opportunities

Environment reset and screenshot capture.

Exception handling

Defects that block testing are escalated immediately with a workaround if possible.

Resulting user experience

The team receives a short list of high value defects and open questions instead of a flood of minor items.

KPIs to evaluate

  • Defects found per session
  • Severity mix
  • Requirement questions resolved
  • Escaped defects after release

What you receive

Concrete deliverables for this service, written so you can check them against the contract.

  • Requirements review notes and acceptance criteria
  • Test charters, scenarios and cases
  • Session reports with evidence
  • Compatibility matrix and results
  • Defect reports with reproducible steps
  • UAT plan and sign off record
  • Accessibility findings
  • Automation candidates list

Technology and engineering

Options we would evaluate for this service. Unless a group is marked as publicly listed on kindlebit.com, treat each tool as a proposed implementation option. Naming a tool does not imply a vendor partnership.

Test management (proposed implementation options)

  • Jira
  • TestRail
  • Xray
  • Azure Test Plans

Environments

  • BrowserStack
  • Sauce Labs
  • Physical device lab

Evidence and accessibility

  • Browser developer tools
  • axe
  • Screen readers
  • Loom style recordings

Relevant Kindlebit work and evidence

We use the strongest evidence available and say which kind it is.

Reference ArchitectureInteractive demo with simulated data

Manual and exploratory testing inside the quality platform

The quality engineering demonstration shows how manual findings feed the release dashboard alongside automation, using simulated data.

Open the demonstration

Business outcomes and success criteria

These are the measures we would agree before work starts. They are criteria for success, not results from past engagements.

Defects found

Valid defects per session and per release.

Escaped defects

Defects found by customers after release.

Compatibility coverage

Share of traffic covered by tested browsers and devices.

Requirement clarity

Requirements clarified before build.

Questions buyers ask

Why do manual testing if we have automation?

Automation checks known behaviour. Exploratory and usability testing find unknown problems and judge experience. They complement each other.

Can you start quickly?

Often within a couple of weeks, depending on environment access and domain knowledge. We begin with a short orientation.

How do you report defects?

With steps, expected and actual results, evidence, environment and impact, in your tracker, so developers can reproduce without a conversation.

Do you test on real devices?

Yes, through device clouds and, where needed, physical devices, chosen from your usage data.

Can testers work in our time zone?

We can arrange overlap with your working hours and agree communication routines.

How does manual testing become automation?

We identify stable, repeated checks during manual work and recommend them for the automation suite.

Related services

Industries where this applies

Put skilled testers on your riskiest release.

Tell us what is shipping and what worries you. We will plan sessions that look where defects hide.

Book a test session Explore a demonstration