Imagine a boutique hotel in Cappadocia with forty rooms. An agency is building it a booking engine that talks to the channel manager and the front-office system, and in the demo everything runs smoothly. Now some awkward questions. A child turns seven halfway through the stay: which rate applies? A reservation covers the night the balloon season opens: whose cancellation terms win? A guest books through the German pages: does the confirmation arrive in German, or half in Turkish? A guest asks for a company invoice: does their tax number make it onto the e-Arşiv invoice intact? Functional testing exists to answer exactly this sort of thing. Pretty screens are not the point; correct application of your rules is. We take the role of a neutral outsider, separate from whoever wrote the code, and work entirely remotely through access to a test environment. What you end up with are specific, documented reasons to accept the delivery or send it back for fixes.
Everything you would want to know before accepting a delivery, captured in writing and reusable next time.
Proposals, specs, tickets, or rules that only exist in your team's heads all get turned into plain written statements. Where two rules clash or one was never defined, we settle it with you first, so nobody argues later about whether something is a defect.
Effort goes to the thresholds: age limits, season boundaries, tiered prices, minimum basket values, time limits that run out at midnight and amounts that change with the number of instalments.
VAT at 1, 10 and 20 percent, validation of Turkish ID and tax numbers, addresses with province, district and neighbourhood, dd.mm.yyyy dates, the decimal comma, and the notorious Turkish capital-letter bug where “i” must become “İ” when uppercased.
Every email, PDF and SMS that reaches someone using the German, English or Arabic interface. Missing translations, the wrong currency and screens that slip back into Turkish mid-transaction.
We trace a single booking or order as it moves to the channel manager, into Logo or Paraşüt, through the iyzico or PayTR sandbox and onto a shipping label.
Once the developer has fixed things, we look not only at the repaired spot but at the flows around it. A fix that quietly breaks something else is the most common delivery surprise.
Reproduction steps, the data used, a screenshot and a severity grade, logged in Jira, GitLab, Azure DevOps or whichever tracker your supplier prefers.
A small application can be covered in a few days; a large system is tested module by module while development continues.
A walk-through of the parts that matter to you, a conversation about business rules, and credentials for the test environment.
Which flow would hurt most if it failed? Test cases are written in that order, and the hour estimate follows from it.
Scripted cases plus free exploratory sessions, defect logging and a regression round after fixes.
Remaining defects by severity and a short call recommending acceptance, conditional acceptance or return.
Make your test data look like your real world. Developer environments are usually full of “Test User” living at “Sample Street 1”. Real customers have ğ, ş and İ in their names, long neighbourhood names in their addresses and apostrophes in their surnames. Seeding test cases with records like these catches a large share of the bugs that would otherwise first appear in production.
Not at all. We start by talking to the people who run the process and poking around the application freely. The rules get written up as we go, leaving you with a document that pays off in every future development round.
Developers know how the software is supposed to behave and instinctively use it that way. An independent tester behaves more like your customers, who do the unexpected. Sensible agencies are glad of it, because a bug caught before launch costs far less to fix.
No, and we would usually advise against it. We work with invented or anonymised records in the test environment. Generating data that looks real but belongs to nobody is the better choice for KVKK and for test quality alike.
At €55 per hour plus VAT, against the estimate we give after the risk map. Teams that release often can also schedule testing as part of a Start, Business or Premium plan.
Besides the defect list and sign-off report, you keep a library of test cases to rerun with every release. The most critical ones can later be turned into automated tests.
What does the application do, who is building it and is there a date for acceptance? We will send you a risk map and an hour estimate.
We have your enquiry
A reply will reach you by the next working day at the latest. If your message says work has come to a halt, it goes to the top of the pile.
No such city in our list. Try another spelling, or just pick the closest big city: we work entirely over remote connections, so nothing about the service changes from one province to the next.
The only cookies here are the essential ones: they keep the site running and remember the city you picked. Nothing is used for advertising or tracking. See our privacy notice for more.
