Requirements review
We read user stories and the specification before code is written. Spotting that one page calculates a discount on the gross price while another uses net costs a single conversation at this point.
Individual bugs are only half the value. The other half is a growing library of scenarios, so that later versions take far less time to check than the first.
We read user stories and the specification before code is written. Spotting that one page calculates a discount on the gross price while another uses net costs a single conversation at this point.
Written steps with an expected outcome, kept in TestRail, Xray or a plain spreadsheet. Our testers, your own staff and, later on, automated scripts can all reuse them.
A Polish NIP with nine digits, a postcode missing its hyphen, surnames containing ł and ż, a basket quantity of 0 or 9999, a date of 29 February. Forms tend to fall over on exactly this sort of data.
Does the order reach Comarch ERP Optima or Subiekt, does the invoice carry the right VAT rate, and does the InPost tracking status flow back into the customer account?
A new feature must not break old ones. After each change we rerun scenarios for the areas the developer touched, plus those that have failed before.
Steps, environment, browser, test data and expected behaviour, entered directly in Jira, GitLab or Azure DevOps. The developer never has to come back asking what was meant.
What was covered, what was left out, which defects remain open and how much risk you accept by shipping this version now.
The first round is slower, since scenarios are written from scratch. Each one after that moves noticeably faster. All work happens remotely against your test or staging environment.
We learn the product and agree with you which features bring in revenue and which can wait a little.
Scope, browsers, devices and anything deliberately excluded. Testing everything is impossible, so risk decides the order.
We work through the scenarios, raise defects and verify fixes as soon as developers hand them back.
A “ship it” or “hold it” recommendation, listing open defects and the areas nobody has covered.
“The basket is broken” is not a bug report. Messages like that bounce between people for weeks and end up closed as “cannot reproduce”. We describe every defect so a developer can trigger it on the first attempt: steps, test account, data, browser and a screenshot or short recording.
It depends on how complex the feature is and how much coverage you want, and the test plan shows the hours before work starts. You can spend less, but then only the main routes get checked and some defects will reach users. Sometimes that is a sensible trade-off, provided it is made knowingly.
No. We begin with exploratory sessions, getting to know the system the way a new user would, and record how it behaves today. As a side effect you end up with your first useful functional documentation.
Yes, on real Android and iOS handsets in a cloud device lab and on emulators. The model list comes from your analytics, because a haulage company app and a fashion store attract very different users.
Individual rounds cost PLN 190 per hour excl. VAT, with an hour cap written into the test plan. Ongoing testing before every release is priced as a fixed monthly fee, so the cost stays predictable.
Describe the system and what worries you about it. We will prepare a test plan and estimate the hours.
Your enquiry has reached us
You will hear back within one working day, and if you have reported an outage that is holding up work, it goes to the front of the queue.
No match for that name. Try a different spelling or pick a bigger town nearby - all our support is delivered online, so your choice has no effect on the service.