Area 12 · Development and web

Software testing and QA

Most firms hear about a defect from a customer first: an angry call to the support line, a one-star review on a marketplace, or month-end figures that refuse to reconcile. By then the bug has already cost money, hours and goodwill. Testing is simply a way of meeting that same bug weeks earlier, quietly and cheaply. Why does the search box return nothing for “IĞDIR” typed in capitals? Where does a few kuruş of difference come from on a nine-instalment card payment? Why does the KDV rate on an e-Arşiv invoice disagree with the product record? Those are the questions we put to your online store, dealer portal, mobile app or the system a supplier has just delivered. Five kinds of test feed one reporting format, and the work runs inside your test environment over remote access, with nobody needing to visit your premises.

5
kinds of test, one reporting format
0
site visits needed
€55
an hour plus VAT, within a cap you sign off
Retest
of every fix before its ticket closes

Matching the test to the risk

Five services for five worries: a screen that calculates wrongly, a server that buckles under a rush, tedious checks repeated by hand for each release, a form where users lose their way, and someone reaching data that belongs to someone else. Not sure which one applies? Just describe the symptom.

Tell us about your application

Functional testing

Does the application really do what the spec or the proposal promised? We probe Turkish-character names and case conversion, tax number and national ID fields, KDV at 1, 10 and 20 per cent, 3D Secure instalments, cash on delivery and return invoices. Afterwards you hold a scenario list to replay whenever a new version is ready.

Load and stress testing

Thousands of simulated visitors hit a replica of your system at once: the 11.11 sale, the minute a gig goes on sale, early-booking morning for a hotel in Antalya. The findings pinpoint whether the bottleneck sits in the database, the checkout step or the image server.

Test automation

Teams shipping weekly soon find manual regression checks falling behind. We script the recurring scenarios in Playwright, Cypress or Appium and hook them into your CI/CD pipeline. Up front we estimate after how many releases the effort breaks even; if it never would, we advise against it.

Usability and UX testing

A dealer placing an order, a patient booking an appointment, a shopper starting a return. A handful of your actual users attempt such jobs on their own computers while we note, over video, every moment they get stuck. An accessibility check based on WCAG 2.1 AA is included.

Penetration testing

We follow the route an attacker would take, with the owner's signed approval and inside limits written into the contract. Priority goes to flaws specific to your application: one dealer viewing another dealer's prices, hijacked sessions, or input fields that open a path into the database.

Typical triggers for a test

At certain points the price of a defect multiplies. An independent check lasting a few days just before such a point saves the weeks of patching and apologising that would otherwise follow.

Taking delivery from a supplier

The agency announces “all done”. Shortcomings spotted before the acceptance record is signed are usually fixed under the existing contract; the same issues found later may be priced as extra work.

After a change under the hood

New payment institution, e-invoice provider, PHP version or server. On the surface nothing moved, yet behind it shipping fees, instalment commissions or invoice series numbers have silently drifted.

Before raising ad spend

A TV spot, an influencer campaign, the November sales. Sending paid traffic to a page that collapses means paying for the same advertising twice.

Before an app goes to the stores

App Store and Google Play review, older Android versions, small screens. A rejected submission pushes the launch back, and a first version that crashes leaves a rating that lingers.

When a security questionnaire lands

A corporate client, a European buyer or a cyber insurance form asks about penetration testing. A report stating scope, date and closed findings is the shortest possible answer.

A good bug report is one a developer can reproduce on the first try. A ticket reading “payment page sometimes fails” bounces between teams for days. One that says which browser, which card, how many instalments, after which step and with what error message is often closed the same afternoon. Every issue we find is written up at that level of detail, so your developers go straight to fixing instead of waiting on answers from the tester.

The working rhythm

You end up with numbered findings ordered by seriousness, not a note saying things are “broadly fine”. We connect to the test environment over a secured remote link or through accounts you open just for this job, and the live system stays untouched.

01

Risk map

Over video we discuss the application, its users and the systems around it, then put at the top of the list the functions whose failure would lose you money, customers or compliance.

02

Plan and cap

Functions in scope, browsers and devices, exclusions and a firm hour limit, all on a single page. Not one hour is logged until you approve it.

03

Test rounds

Findings land on your own board in Jira, GitLab, GitHub or Azure DevOps with screenshots and test data attached. Each evening brings a short tally of critical, medium and minor items.

04

Confirmation and verdict

Fixes are verified one at a time, and the area around each repair is re-examined. The closing report ends with an explicit recommendation: release as it stands, or close specific items first.

Frequently asked questions

Functional, load and usability work mostly happens from the user's side of the screen, so a test environment and a few test accounts are enough. Automated tests are healthiest when they live in your repository alongside the code, which is why automation needs limited repository access. For penetration tests it depends on whether you choose a black-box or white-box approach in the contract.

No. A scan uses automated tools to look for known weaknesses: broad coverage, little depth. In a penetration test a specialist studies your business logic and spends hours trying things by hand. Can a dealer login open another dealer's orders? Can a refund be fired twice? Scanners miss that sort of flaw. Your hosting company's terms may require advance notice of a pen test, and we settle that with you before any work begins.

A week or two usually covers functional checks on a smaller application. For load testing ahead of a major campaign allow a month at least, since the first round of measurements prompts tuning and a second round. Penetration test timing is driven chiefly by approvals and by correspondence with your hosting company.

Single assignments are invoiced at €55 an hour plus VAT and never exceed the cap in your approved quote. Where every release needs regular testing, the work can sit inside a Start, Business or Premium monthly plan. Invoices come as PDF by email, payable within 30 days. Since the service is bought from abroad, check with your mali müşavir how KDV should be declared at your end.

Ideally no genuine records should be there, so we suggest invented data or a masked copy. If real data truly cannot be avoided, a data processor agreement under KVKK is signed first, access is kept as narrow as possible, logged throughout and revoked at the end. Special categories of personal data, such as health information, get no exceptions to that rule.

Catch the bugs before your customers do

Say what needs testing and when you intend to release. We will reply with a test plan and an hours estimate.

Availability
Weekdays 09:00-18:00 Turkey time (GMT+3); an answer follows by the next working day
Calls
By video, over Microsoft Teams or Google Meet

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.