Solfreaks AppTest Lab is how we handle mobile app QA and testing: manual passes on real phones, automated UI tests for the flows that must never break, and bug reports a developer can act on without a phone call to explain them.
We test apps we built and apps other agencies built. The usual starting point is a release a week away and an app that has only ever run on the developer's own handset.
What lands in your tracker
- A written test plan. It lists the screens, flows and risks we'll cover, so you know what we mean by tested before we start.
- A device matrix. Built from your analytics or store statistics where we can, and always including cheap, older Android phones alongside current iPhones and Pixels.
- Regression runs before each release. The checklist grows every time a bug slips through to production, so the same mistake doesn't happen twice.
- Bug reports with evidence. Each one has steps, expected and actual result, device and OS version, and a screen recording when the problem is visual or depends on timing.
- Automated UI tests. We write them in Espresso, XCUITest, Appium or Maestro, whichever fits your stack, for sign-up, login, payment and the other flows you can't afford to break.
- Quality notes beyond bugs. Start-up time, memory growth, battery drain, TalkBack and VoiceOver support, and basic security checks such as data stored in plain text or keys sitting inside the app.
- A release verdict. After each round we say plainly whether we'd ship, and what we'd fix first if you decide to ship anyway.
What we test first when time is short
Time is nearly always short, so we start with the paths that cost you money or users: install and first launch, sign-up and login, anything that takes a payment, then the one feature people open the app for. After that come the upgrade path (the new version installed over an old one with real data in it), permission prompts, and what happens on a bad connection or when the system kills the app mid-task. Visual polish comes last. A misaligned icon is irritating; a crash at launch on a budget Android phone is a one-star review.
How a test round runs
- Get to know the app. We use it for a day or two, talk to whoever built it, and write the test plan from what we find.
- Agree the devices. We borrow, buy or rent what's missing; cloud device farms such as Firebase Test Lab cover the gaps.
- Test in rounds. A first full pass on a small or medium app usually takes several days. Later regression passes are quicker.
- Report as we go. Bugs go into Jira, Linear, GitHub or whatever you use on the day we find them.
- Retest and sign off. When fixes land we verify them, re-run the affected flows and give the verdict.
Inside a sprint, we take each story the day it's ready, write test cases while developers build, and save the full regression pass for the release candidate. With a build pipeline, the automated tests run on every commit, which is where our DevOps and CI/CD work meets QA.
Who benefits, and who doesn't
It suits teams that ship regularly without a tester, founders with a nearly finished app who want a second pair of eyes before store review, and agencies short of testing capacity. It also fits a Google Play closed test or a first App Store review, where one thorough pass can save a rejected build. Our app publishing work covers the store side.
Hold off if you want a promise of zero bugs; no tester can give one. It's also overkill to commission an automated suite for a five-screen prototype that will be rewritten next month. And if nobody can say what the app is supposed to do, you need a spec before you need testers.
Testing costs and turnaround
Price follows the size of the app, how many devices and OS versions need covering, how much automation sits on top of the manual testing, and how often you release. We quote a fixed scope for a one-off round, such as a pre-launch test, and a monthly arrangement for frequent releases. A one-off round typically takes one to three weeks. An automated suite takes longer, usually a few weeks to start, and needs upkeep as the interface changes. The quote follows a short discovery call. Fixing the bugs is separate work, unless the app is also on one of our maintenance plans.
Why Solfreaks for testing
You message the person who is testing your app, and our Rawalpindi working day overlaps with the UK and the Gulf. We've published apps on Google Play ourselves, so we know how the store's pre-launch checks and review feedback show up in practice. Test scripts live in your repository and tickets in your tracker, so nothing is held back if you part ways. When you're ready, tell us what you need and we'll set up a call.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- appium/appiumCross-platform UI automation for mobile apps.
- mobile-dev-inc/maestroSimple UI testing for mobile and web apps.
- android/testing-samplesOfficial Android testing samples.
- wix/DetoxGray-box end-to-end testing for mobile apps.
Frequently asked questions
Which phones will you test on?
We start with your analytics or Play Console device data, if you have it, and pick the phones and OS versions that cover most of your real users. Cheap Android handsets with little memory always get a place, because that's where apps break first. iPhones are chosen by iOS version rather than model. Cloud device farms fill the gaps, and you're welcome to tell us which devices matter to you.
Do you write automated tests, or is it all manual?
Both, in that order. Manual testing finds the problems nobody predicted, so it comes first. Once a flow is stable we automate it, using Espresso or XCUITest when the app is single-platform and Maestro or Appium when one test suite should cover both. Automated tests save time on regression but need upkeep every time screens change, so we only automate what's worth maintaining.
Can you test an app you didn't build?
Yes, and it's common. For black-box testing we need an installable build (an APK or a TestFlight invite), test accounts for each user role, and a staging backend if there is one. We don't need the source code. If you can also give us the issue tracker and some notes on intended behaviour, the first round goes faster and the bug reports land where your developers already work.
What do you need from us to start?
Mostly access and context: a build, test accounts and the order of the main flows. A short walkthrough call helps us learn which behaviour is intended and which is a bug. Analytics or store data on devices and OS versions lets us choose phones sensibly. If payments, SMS codes or third-party logins are involved, we need test credentials, since we can't use real money or other people's phones.
How much time does testing add before a release?
A regression pass on a modest app usually takes a few days. If we test alongside development, as stories finish, the extra time before release shrinks a lot, because only the final pass is left. What stretches schedules is the fix-and-retest cycle, which depends on how quickly developers respond. We flag blocking bugs the same day so you aren't surprised near the deadline.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
