QA and software testing services
Manual and automated testing for iOS, Android and web products, either inside a project we develop or as an independent check of a product built by another team. You get reproducible bug reports and a clear picture of what could go wrong at release.
When you need a QA team
Testing pays for itself when a bug in production costs more than finding it earlier. These are the situations we hear about most often.
- Users report bugs your team never saw
- Every release breaks something that used to work
- Developers test their own code and nobody else checks it
- App Store or Google Play review rejected your build
- You are about to launch and want an outside check first
- The product slows down or fails when traffic grows
What we test
Manual testing
QA engineers go through the product step by step against requirements and test cases, on real devices and in browsers. They also explore areas no test case covers yet, the way a new user would.
Test automation
We automate the checks that must pass on every build: sign-up, payments, other core flows and the API. The suite runs in your CI/CD pipeline and flags failures before a release goes out.
Performance testing
We measure response times and throughput under load and find the point where the product starts to fail. The report lists the bottlenecks in the order they should be fixed.
Security testing
We check how the product stores and transmits data, how sign-in and permissions work, and what the code and third-party libraries expose. Each finding comes with a risk rating and a recommended fix.
Mobile and store checks
Testing on real iOS and Android devices, not only simulators, across the OS versions your users actually have. We also check builds against App Store and Google Play rules so review does not reject them.
API and integration testing
Your backend, payment providers and third-party services are tested together, including the failure cases: timeouts, declined payments, incomplete data. This is where production incidents usually start.
Testing that runs alongside development
Testing that starts after development finds problems when they are most expensive to fix. In our projects a QA engineer joins at the requirements stage, writes test cases while features are being built and checks every sprint build rather than only the final one. By release day the team already knows where the weak spots are. The same approach works when our testers join your existing team.
- Requirements reviewed for gaps before code is written
- Test cases ready by the time a feature is ready
- Every sprint build checked, not only the release candidate
- Regression testing before each release
Manual or automated testing?
Manual testing gives judgement: a person notices that a flow is technically correct and practically unusable. Automation gives repetition: the same hundred checks after every commit, at night, without fatigue. Small projects and short-lived features rarely earn back the cost of writing automated tests, and we say so instead of selling them. Long-lived products with frequent releases earn it back quickly, so most mature products end up using both.
- Manual: new features, usability and products that change every week
- Manual: exploratory testing of unclear or risky areas
- Automated: core flows that must never break, checked on every build
- Automated: regression suites for products with frequent releases
- Both: automation for the stable core, people for everything new
What you receive
Everything we produce stays with the project, so the next tester, ours or yours, does not start from zero. A bug that cannot be reproduced is not a finding, and we do not report it as one. Each release ends with a short report on what was tested and which risks remain, so the decision to ship is yours and an informed one.
- Test cases and checklists stored in your tracker or repository
- Bug reports with steps, environment, expected and actual result
- Release report: what was covered and which risks remain
- Automated test suite with instructions to run it, where automation was agreed
How testing works
Product review
We study the requirements, or the product itself when there is no documentation, and agree which platforms, devices and flows matter most. You get a testing scope and plan.
Test cases
We write test cases and checklists for the agreed scope. They are kept in your tools and stay with the project.
Testing builds
Each build is tested on real devices and in the target browsers. Bugs go into your tracker with everything needed to reproduce them.
Automation where it pays
For flows checked on every build we write automated tests and connect them to your CI pipeline. You see the results with every commit.
Release report
Before each release you get a summary of what was tested, what was fixed and what risks remain.
Platforms and tools
Platforms
- iOS
- Android
- Web browsers
- REST APIs
Automation
- Playwright
- Selenium
- Appium
- XCUITest
- Espresso
- Postman
Performance and security
- Apache JMeter
- k6
- OWASP ZAP
Workflow
- Jira
- TestFlight
- Google Play testing tracks
- Firebase Crashlytics
Ways to work with us
QA in a project we develop
A tester is part of the team from the first sprint, and testing is planned together with development.
Testing a product built elsewhere
A fixed-scope check of an existing product or a specific release: test cases, bug reports and a written assessment of its condition.
QA engineers in your team
Our testers work in your process and your tracker, billed by the hour or as a dedicated engineer.
Reviews
We treat each client and his project with love.
Revol team continues to streamline the client’s development capabilities through their high-quality work and reliable support. They communicate effectively and exhibit a strong understanding of the client’s needs and business.
Tomas
The work from Revol, have fully met expectations and satisfied the client. Their fresh approach and ability to remain available for support have been valuable assets. Customers can bring them on for a communicative, client-oriented team to achieve their goals with.
Andrey
Frequently asked questions
Can you test a product you did not build?
Yes. We start with the requirements, or with the product itself when there is no documentation, and write test cases from there. The first result is usually a list of the most serious problems plus a test plan for the rest.
Do you provide testers for our own team?
Yes. QA engineers can work inside your process, your tracker and your release schedule, the same way our developers do in team augmentation.
Should we automate our tests?
Only where the tests will run often enough to repay the cost of writing and maintaining them. For a long-lived product with frequent releases that usually means the core flows and the API. For a prototype or a short-lived feature, manual testing is cheaper, and we will tell you so.
Which devices do you test on?
Real iOS and Android devices, plus simulators and emulators for wider OS version coverage, and the main desktop and mobile browsers. The device list is agreed at the start, based on what your users actually have.
Can you help after an App Store or Google Play rejection?
Yes. We read the review feedback, reproduce the problem, check the build against the current guidelines and tell the developers exactly what to change. If we develop the app, we fix it and resubmit it ourselves.
How is testing priced?
It depends on the format. A one-off check of a product or a release is usually a fixed scope; ongoing testing is billed by the hour or as a dedicated engineer. After reviewing the product we suggest a format and send an estimate.
Tell us about your project
Describe the task in a few lines. Within one working day we reply with questions or a first view on scope and cost.
Prefer email or a call?
welcome@revolsource.com
+38 097 662 23 20
Revol Software OÜ, Tallinn, Estonia. Our team is distributed around the world.
Join our team
Send your CV to career@revolsource.com