Services Optimization
QA & testing
Manual and automated testing that finds faults before your customers do, with clear reports your team can act on.
At a glance
- Includes
- Test plans, manual testing, automated end-to-end tests and defect reports
- Works with
- Websites, web applications and mobile apps, in your test or staging environment
- Delivered as
- Test plans, automated tests in your repositories and written defect reports
- Starts with
- Your requirements and the journeys that matter most
Fit
Is this right for you?
Usually the right call when one of these sounds familiar.
Customers find the bugs
Faults reach production and are reported by users.
Testing before a release is rushed
Time runs out, so checks get shortened.
The same checks done by hand
Every release repeats a long list.
Nobody owns quality
Testing falls between developers and managers.
Not the right service? Running the tests on every change: CI/CD pipelines. Finding weaknesses in security: Security audits.
Scope
Scope and what you get
Testing is planned from your requirements and reported in plain language. Each piece of work has a matching thing you receive.
- What we do
Test planning
A plan written from your requirements, naming the journeys and conditions to check.
What you receiveA test plan you can read
A document your team and ours both work from.
- What we do
Manual testing
Exploratory and scripted testing on the devices and browsers you choose.
What you receiveDefect reports
Each fault written up with steps to reproduce, so a developer can act at once.
- What we do
Automated end-to-end tests
Critical journeys such as sign-up and checkout turned into repeatable tests.
What you receiveTests that run themselves
Automated tests in your repositories, ready to run in your pipeline.
- What we do
Regression checks
The same tests rerun on every release to catch faults that return.
What you receiveA release summary
What was tested, what failed and what is still open.
Use cases
Relevant use cases
Practical situations where this service is put to work. Open a card to see how it applies.
Testing a release before launch
A structured round of testing across the features and devices that matter before a launch.
- Plan written from your requirements
- Defects reported with steps to reproduce
- A summary of what is open at release
Automating the checks that repeat
The most important journeys turned into automated tests, so they no longer depend on memory.
- Journeys chosen with your team
- Tests stored in your repositories
- Run on every change in your pipeline
Checking a site across browsers and devices
Testing on the browsers and devices your customers use, not only the ones in the office.
- Devices and browsers agreed in advance
- Layout, forms and journeys checked on each
- Findings grouped by area
Sample use cases, drafted as placeholders. The Plethora team confirms the final list.
Process
How it works
Four stops, agreed with you as we go. Each shows what we do and what we need from you.
Understand
We doWe read your requirements, try the product and agree which journeys matter most.
You doYou share requirements, access to a test environment and test accounts.
Plan
We doWe write the test plan and agree devices, browsers and how defects will be reported.
You doYou review the plan and tell us what to leave out.
Test
We doWe run manual tests and build automated ones, reporting faults as we find them.
You doYou triage the reports and fix what you decide to fix.
Report
We doWe retest the fixes and give you a summary of what passed and what remains.
You doYou decide whether the product is ready to release.
Quality
Quality and handover
How the work is checked, accepted and passed to you.
Reproducible reports
Every defect carries the steps and environment needed to see it again.
Plan agreed in advance
So you know what has and has not been tested.
Tests you own
Automated tests live in your repositories and run without us.
Plain summary
A short release note on what passed, what failed and what is open.
Tools
Tools and technology
Tools we use in delivery. We choose them to suit your team, and the list does not imply any partnership. Logos belong to their owners.
- Playwright
- Lighthouse
- k6
- GitHub Actions
- GitLab
Engagement
Engagement and cost factors
Ways to work with us
A scoped project
A defined round of testing for a release or a feature.
A team alongside yours
Testers work in your team, in your tracker and your sprints.
Ongoing support
Regular testing for each release as the product changes.
What shapes scope, timing and cost
- How many features, devices and browsers are in scope
- How much of the testing should be automated
- The state of your requirements and documentation
- Whether you need testing for every release or one-off
- The test environments and data available
Scope and cost are confirmed with you in writing before work starts.
FAQ
Frequently asked questions
They help, but we can work from the product, your tickets and conversations with your team, and write the requirements down as we go.
Yes. We report defects in your tracker, in the format your developers prefer.
No. Automation is good at repeating checks. People are better at noticing what looks wrong. Most products need both.
You do. Automated tests are delivered into your repositories.
Catch faults before your customers do. Start with a conversation.
Tell us what you run today and we will come back with next steps.
Talk to usRelated