How much does software testing and QA cost in Dubai?

A focused test pass on an existing build starts from around AED 4,000. That covers a written test plan, test cases across your core flows, execution on your main browsers or devices, and a defect log with severities you can hand to your developers. On projects where QA is planned in from the start rather than added at the end, we typically see it land at around 10 to 15 percent of the build budget. Those are our own figures, not a market survey. Final pricing depends on scope.

Is software testing just the developer checking their own code works?

No. Testing is a structured set of activities that includes reviewing requirements and code without running anything, designing test cases against agreed requirements, executing them at several levels, and reporting results. A developer checking their own feature is one small part of it, and it is the part most likely to miss what the developer did not think of. The international testing standard describes a full process covering planning, design, execution and reporting, not a single click-through before release.

What is the difference between unit, integration and system testing?

Unit testing checks one small piece of code on its own, usually written by the developer as they build. Integration testing checks that pieces work together correctly, such as whether the payment module hands off properly to the order module. System testing checks the whole assembled application against requirements in an environment close to production. This sequence is the standard structure described in ISO/IEC/IEEE 29119. Each level catches a class of problem the level before it structurally cannot see.

Do we need a dedicated QA person, or can developers test their own code?

No standard mandates a separate QA role, so this is a risk judgment rather than a rule. Developers testing their own units is normal and expected. What it does not replace is independent system-level and acceptance testing, because the person who built something is the worst person to find the assumption they built into it. The more your product touches money, personal data, or a workflow people depend on, the earlier independent testing earns its cost.

What is regression testing and why does it keep coming up?

The ISTQB Glossary defines it as testing a previously tested program after a modification, to confirm that defects have not been introduced or uncovered in parts of the software that were not changed. It comes up constantly because every release risks breaking something that used to work fine. It is also the single test type that most rewards automation, since you run the same checks again on every release for as long as the product exists.

What is exploratory testing and is it worth paying for?

The ISTQB Glossary defines it as a technique where the tester actively controls the design of the tests as they are performed, using what they learn to design new and better tests. In plain terms, a skilled person hunts for trouble without a script. It finds usability dead ends and edge cases no written test case would have thought to check. It is worth paying for as focused, skilled effort on new features, not as a repeated routine check.

Should we automate our tests or test manually?

Automation costs more upfront, because someone has to write the scripts and then keep them working, and it only pays back on checks you run repeatedly. Automate regression suites and the paths that must never break. Keep manual the things that change often, the judgment calls about whether a screen makes sense, and exploratory bug hunting. No authority publishes a numeric threshold for when automation starts paying back, so treat any specific number you are quoted as opinion.

Can automated tests replace a human tester entirely?

No, because they do different jobs. Automated tests repeat the same check reliably and cheaply, which is exactly what regression testing needs. But they only ever find what someone wrote them to look for. Exploratory testing depends on a human adapting the test design in real time based on what they are learning, which a fixed script cannot do by definition. The sensible setup is automation for the repeated checks and human judgment for everything else.

What does performance and load testing actually check?

Performance testing measures how the system behaves under expected and peak use: response times, throughput, and how much memory and processing it consumes. Load testing pushes concurrent users or requests up until something slows badly or falls over. It surfaces problems that only appear at scale, such as slow database queries or connection limits. It will not find a single functional bug. A system can be fast and still give the wrong answer, so the two are separate concerns.

Is security testing the same as penetration testing?

Related, but not the same. Security testing is the broad discipline of looking for ways a product could be attacked. A penetration test is one method inside it, where a tester simulates an attacker against an agreed scope. OWASP publishes the Top 10 list of critical web application security risks and the Web Security Testing Guide, which is the methodology reference most serious testing follows. Penetration testing is scoped and priced differently from functional QA, so treat them as separate lines.

What does accessibility testing check?

Whether people using screen readers, keyboard-only navigation, or with low vision or limited motor control can actually use your product. In practice that means colour contrast, tab order, alternative text on images, properly labelled form fields, and tap targets large enough to hit. The standard is WCAG from the W3C Web Accessibility Initiative, with conformance levels A, AA and AAA. When a contract or policy asks for WCAG compliance, W3C notes it almost always means Level AA.

What is user acceptance testing and who should run it?

The ISTQB Glossary defines acceptance testing as formal testing against user needs, requirements and business processes, to determine whether the system satisfies the acceptance criteria and to let the customer decide whether to accept it. You or users you nominate should run it, against your real business scenarios. Our own recommendation is that those scenarios are written before the build starts. Written afterwards, you end up testing what was delivered rather than what you actually wanted.

Who should write the test cases, us or the development team?

The normal split is that developers write and own unit tests because they know the code, the QA function writes integration and system test cases against agreed requirements, and you or your nominated users run acceptance testing against your own business scenarios. This is common practice rather than a rule set by any standard. The failure mode is assuming the developer covers all three levels. Most do not, and most never said they would, so ask early.

What should be in our definition of done for a feature?

At minimum three things: which test levels must pass, what defect severities are allowed to remain open at sign-off, and what is handed over alongside the code, such as test results and a known-issues log. Agree it before the sprint that builds the feature, not after. It works on my machine is not a definition of done. System tests pass, no open critical or major defects, results delivered, is one you can actually check against.

If a bug shows up after launch, who pays to fix it?

It depends entirely on what your contract says, so agree it before work starts. The usual structure is a warranty window after launch, commonly thirty, sixty or ninety days, during which genuine defects are fixed at no extra charge. The number matters less than the clause existing and being clear about where the warranty ends and paid maintenance begins. Without it, every post-launch bug becomes a negotiation, and negotiations under time pressure rarely go your way.

What is the difference between a defect and a change request?

A defect is the software not doing what the agreed requirements said it would do, and fixing it is the vendor's responsibility. A change request is new or altered scope, something that was never specified or has since changed, and it is billable as new work. Write both definitions into the contract using examples from your own product, and write down the escalation path for when you disagree. This single clause prevents more disputes than any other.

Our developer delivered with no test plan. Is that normal?

It is common, but it is not good practice. ISO/IEC/IEEE 29119 describes a test process covering planning, design, execution and reporting, and it is written to be tailored to the size of the project, including small ones. A partner who produced no plan, no test cases traceable to requirements and no defect log is not simply working informally. They are working outside the structure the international standard describes, and you have no record of what was checked.

How do we know the developer actually tested the app properly?

Ask for the artefacts a real test process produces: a test plan, test cases you can trace back to specific requirements, a defect log with severities, and a summary report against agreed exit criteria before sign-off. If none of those exist, testing probably meant one person clicking through the feature once. Also ask which test levels they run and who runs each one. A clear answer shows a process. We test everything thoroughly shows nothing.

Is an ISTQB certification meaningful or just a line on a CV?

It is a reasonable baseline signal. ISTQB is the recognised international qualification body for software testers and publishes the Certified Tester Foundation Level syllabus and the ISTQB Glossary of testing terms. Holding it means someone has been examined against a common international body of knowledge. Holding it means someone has been examined against a common international body of knowledge. It is not a guarantee of quality on your specific product, and plenty of excellent testers do not hold it. Use it as one input among several, not as a filter.

What is static testing if no code is run?

Static testing means reviewing artefacts without executing the software: requirements reviews, design reviews, code reviews and walkthroughs. It sits alongside dynamic testing, where you actually run the thing, and both belong in a serious test plan. It matters because an ambiguous requirement caught in a review costs a conversation, while the same ambiguity caught after launch costs rework in code, in data, and sometimes in what users have already learned to do.

We are a small team. Is QA overkill before we have real users?

No standard sets a team size or user count where QA becomes necessary, so this is a judgment about risk rather than scale. The more your product touches money, personal data, or a compliance-sensitive workflow, the earlier structured testing pays for itself. For a low-risk internal tool with a handful of users, a disciplined manual test plan is often enough. What is rarely enough is no written plan at all, whatever the size of the team.

Does UAE law require my app to meet WCAG accessibility standards?

It is confirmed for government platforms. The UAE National Policy for Digital Accessibility sets requirements for government digital services, and the official UAE Government Portal states it is built to meet WCAG 2.1 and 2.2 Level AA as a minimum. For private commercial software generally, we could not confirm a UAE legal requirement in our research, so we are not going to assert one either way. If it affects a contract you are bidding for, take your own legal advice.

Does VAT apply to QA and testing services in Dubai?

Yes. QA and testing supplied by a UAE provider is a service and carries the standard 5 percent VAT where the supplier is VAT-registered, which is mandatory above AED 375,000 of taxable turnover according to the Federal Tax Authority. When you compare quotes, check whether each figure is stated before or after VAT, because that alone can change which quote looks cheaper. If an overseas supplier is involved, check the treatment with your accountant.

How much of our development budget should go to QA?

No government body, regulator or standards organisation publishes a benchmark for this, so anyone quoting one is quoting an opinion. In our own projects, when QA is planned in from the start rather than bolted on at the end, it typically lands at around 10 to 15 percent of the build budget. That is our observation of our own work, not an industry figure. Bolted on late, it costs more and buys less, because rework is already priced in.

Is it true that around half of a software budget goes to testing?

We would not repeat that figure. It circulates widely and is usually attributed to research that does not actually contain it, and we could not trace it to any credible primary source. There is a genuine government study in this area, the NIST Planning Report 02-3 on the economic impacts of inadequate software testing infrastructure, but it was published in 2002, it is an economy-wide estimate for the United States, and it is not a project budgeting rule.

Is there a published day rate for QA testers in Dubai?

Not from any authority we could find. Standards bodies publish methodology, not prices, and no UAE government body publishes rates for QA work. What exists is what providers publish about their own commercial figures, ours included, and those are quotes rather than surveys. Treat any number presented to you as a market rate with the same suspicion you would treat any other unsourced statistic, and ask what scope of work the figure actually covers.

What happens if we skip QA and just fix bugs as users report them?

Your users become your test team, which costs you their patience rather than your budget in the short term. The general principle, and it is directional rather than a measured multiplier, is that defects cost more to fix the later they are found, because by then the problem is baked into code, into stored data, and into habits people have formed around it. Production bug fixing also arrives without warning, which is the worst way to schedule engineering work.

Do we need a separate QA contract or is it part of the development agreement?

Either structure works and no standard dictates one. What matters is that the same six things are written down somewhere: which test levels are covered, who writes and runs the test cases, the definition of done, the severity and priority scales, the warranty period for post-launch defects, and the change request process. If QA is buried inside a development agreement as one line saying testing included, that line is doing no work at all.

What is the biggest tell that a delivery partner is under-testing?

No documented test plan, no defect log with severities, and testing that turns out to mean the developer clicking through their own feature once before shipping. None of that matches the process structure the international testing standard describes, or the level structure running from unit through to acceptance. A second tell is vagueness about who fixes what after launch. Partners with a real process answer that question in specifics, because they have had to answer it before.

App DevelopmentAugust 7, 2026

Software Testing and QA Services in Dubai: What to Agree Before Anyone Writes a Test

SKIMBOX Team

A focused QA test pass on an existing build in Dubai starts from around AED 4,000. Here is what each test type actually catches, when automation is worth it and when it is not, and the contract terms that decide who pays when a bug turns up after launch.

Nobody argues about software testing until something breaks in production. Then the argument starts, and it is almost never a technical one. It is about who was supposed to write the test cases, what done was meant to mean, whether the thing users are complaining about is a defect or a change request, and who is paying to fix it.

That is the part most buyers get wrong. Testing feels like a technical service you can buy later. It is actually a set of agreements you needed at the start. The tests themselves are the straightforward bit. The terms around them decide whether a bug costs you nothing or costs you a month of billed work.

So this guide starts there. Then it explains the test types plainly, gives our own figures for what QA work costs in Dubai, and separates what UAE regulation actually requires from what people assume it requires.

Testing is a contract question first

Two teams can run identical tests and end up in completely different places. The difference was written down before the build, not discovered after it.

Here is what that looks like. A client reports that an invoice total is wrong. The developer says the specification never mentioned rounding at line-item level, so this is new work. The client says an invoice that adds up incorrectly is obviously broken. Both are being reasonable. Neither of them wrote down precisely enough what an invoice was supposed to do, and neither wrote down who decides when they disagree.

There is an international standard for testing, and it is worth knowing it exists. ISO/IEC/IEEE 29119 is the software testing standard [1], and it defines a test process covering planning, design, execution and reporting [2]. It is written to be tailored to the project, from a small internal tool up to a regulated system. It does not dictate your contract. But it does mean that a delivery partner who produced no test plan, no test cases traceable to requirements, and no defect log is not merely working informally. They are working outside the structure the international standard describes.

The five things to agree before testing starts

1. Who writes the test cases. The normal split is that developers write and own unit tests, because they know the code. The QA function writes integration and system test cases against agreed requirements. You, or users you nominate, run acceptance testing against your own business scenarios. The failure mode is assuming the developer covers all three. Most do not, and most never said they would.

2. What done means. Write the definition of done for a feature before the sprint that builds it. At minimum: which test levels must pass, what defect severities may remain open at sign-off, and what is handed over besides the code. It works on my machine is not a definition of done. System tests pass, no open critical or major defects, results and a known-issues log delivered, is one you can check against.

3. Severity and priority, as two separate scales. Severity is technical impact. Priority is business urgency. They move independently, and pretending they are the same causes most of the shouting. A rare crash in an admin screen nobody opens this month is high severity and low priority. A misspelled company name on the homepage in launch week is low severity and high priority. Define both scales, and say who rates what. On our projects QA proposes severity, and the product owner and delivery team agree priority together.

4. Defect or change request. This is the clause that saves the most money. A defect is the software not doing what the agreed requirements said it would do, and fixing it is the vendor's job. A change request is new or altered scope, and it is billable. Write both definitions into the contract using examples from your own product. Then write the escalation path for when you disagree, because at some point you will.

5. The warranty window. Agree in writing how long after launch genuine defects are fixed free, and where that period ends. Thirty, sixty or ninety days are all common. What matters more than the number is that the clause exists and separates warranty from ongoing maintenance, which is a paid service that starts when the warranty stops. Our app maintenance guide covers what that costs.

Get those five written down and most testing disputes stop before they start.

The test types, in plain language

Test levels run in a sequence, and each level catches things the one before it cannot [1].

Unit testing checks one small piece of code on its own, normally written by the developer as they build. It catches logic errors early, before they compound. It cannot tell you whether the assembled system works.

Integration testing checks that pieces work together: does the payment module hand off correctly to the order module. It catches interface and data-handoff bugs. If your product connects to other systems, this is where most surprises live, which is why our system and API integration guide treats integrations as their own piece of work rather than one line in a brief.

System testing checks the whole assembled application against requirements, in an environment close to production. It catches what only appears once everything is wired together.

Acceptance testing is the formal gate. The ISTQB Glossary defines it as formal testing with respect to user needs, requirements and business processes, conducted to determine whether the system satisfies the acceptance criteria and to enable the customer to decide whether to accept it [3]. In plain terms, this is where you decide the thing does what you asked for. Write the scenarios before the build. Written afterwards, you test what was delivered rather than what you wanted.

Then there are types that cut across all the levels.

Regression testing is defined by the ISTQB Glossary as testing a previously tested program following modification, to ensure defects have not been introduced or uncovered in unchanged areas of the software [4]. Every release risks breaking something that used to work. This is the type that most rewards automation, because you run it again every single time.

Exploratory testing is defined by the ISTQB Glossary as a technique where the tester actively controls the design of the tests as those tests are performed, using information gained while testing to design new and better tests [5]. A skilled person hunting for trouble without a script finds things no written test case would have thought to check. It cannot be automated, because the value sits in the human adapting in real time.

Performance and load testing measures response times and behaviour under expected and peak use, to find where the system slows or falls over. It says nothing about whether the answers are correct. Fast and wrong is still wrong.

Security testing looks for ways the product could be attacked. OWASP publishes the Top 10, a consensus list of the most critical web application security risks [6], and the Web Security Testing Guide, the methodology reference most real security testing follows [7]. A penetration test is one method inside that discipline, scoped and priced differently from functional QA. We cover it separately in our penetration testing guide.

Accessibility testing checks whether people using screen readers, keyboard-only navigation, or with low vision can actually use the product. The standard is WCAG, published by the W3C Web Accessibility Initiative, with conformance levels A, AA and AAA [8]. W3C notes that when legislation, policies or contracts require WCAG compliance, they almost always mean Level AA [9]. Design decisions drive much of this, which is why it belongs in the design phase rather than the week before launch, and our UI and UX design guide treats it as part of the work.

Manual or automated? The honest answer

Automation is oversold. It costs more upfront, because somebody has to write the scripts and then keep them working, and it only pays back on things you run over and over.

That makes the decision reasonably simple. Automate the checks that repeat: regression suites, the paths that must never break, cross-browser and cross-device checks that run on every release. Keep manual the things that change constantly, the judgment calls about whether a screen makes sense, and the exploratory hunting that finds the bugs nobody scripted [5].

Automating too early is a real and expensive mistake. If the interface is still moving every week, every change breaks the scripts, and you now maintain two products instead of one. Plenty of smaller projects are genuinely better served by disciplined manual testing, with a written test plan and a proper defect log, than by an automation suite nobody updates. That is our operating view rather than a rule from any standards body. No authority publishes a threshold for when automation starts paying back, so treat any specific number you are quoted as an opinion.

What QA costs in Dubai

No government body, regulator or standards organisation publishes rates for QA work. ISO, IEEE, ISTQB, the W3C and OWASP publish standards and methodology, not prices. The figures below are our own, based on what we quote. They are not a market survey.

A focused test pass on an existing build starts from around AED 4,000. That covers a defined scope: a written test plan, test cases across your core flows, execution on your main browsers or devices, and a defect log with severities you can hand straight to your developers.

On projects where QA is planned in from the start rather than bolted on at the end, we typically see it land at around 10 to 15 percent of the build budget. That is our own observation across our own projects, not an industry benchmark.

You will also see a claim that around half of a software project budget goes to testing. We would not repeat it. That figure does not trace to any credible source we could find, and the research it gets attributed to does not say it. There is one genuine government study in this space, the NIST Planning Report 02-3 on the economic impacts of inadequate software testing infrastructure [10]. It was published in 2002, it is an economy-wide estimate for the United States, and it is not a project budgeting rule for anyone.

For context against our published build figures: custom software starts from around AED 15,000 for a focused first version and around AED 60,000 for a fuller system [11]. App maintenance starts from around AED 500 a month [12]. Penetration testing is a separate discipline with its own scoping and its own pricing [13]. QA sits alongside these rather than replacing any of them. Services from a VAT-registered UAE supplier carry the standard 5 percent VAT, and registration is mandatory above AED 375,000 of taxable turnover [14]. Final pricing depends on scope.

The UAE-specific parts

Government platforms have a confirmed accessibility baseline. The UAE National Policy for Digital Accessibility sets requirements for government digital platforms [15], and the official UAE Government Portal states that it is designed to meet WCAG 2.1 and 2.2 Level AA as a minimum [16]. If you are building for or selling into a government entity, assume that bar and test against it.

For private-sector software, we could not confirm a general requirement. We found no UAE federal or Dubai law in this research that mandates a specific software testing regime, or WCAG conformance, for private commercial software generally. We are saying that plainly rather than claiming it is required or claiming it is not. If accessibility or testing conformance affects a contract you are bidding for, read the tender documents and take your own legal advice.

Financial services are the confirmed exception, and only them. The Central Bank of the UAE requires licensed financial institutions to maintain technology and information security risk frameworks that include testing obligations, covering annual penetration testing and quarterly vulnerability assessments [17]. That applies to CBUAE-licensed entities such as banks, payment service providers and stored-value facility licensees. It is not a general rule for software companies or apps, and anyone extending it to your product is stretching it.

How to tell whether your partner is actually testing

Ask for the artefacts. A real test process produces a test plan, test cases you can trace back to requirements, a defect log with severities, and a summary report before sign-off. The international standard describes a test process covering planning, design, execution and reporting [2]. The severity scale and the exit criteria are things you and your partner agree between you, not something the standard hands you. If none of those exist, testing probably meant one person clicking through the feature once.

Two more useful questions. Ask which test levels they run and who runs each one. Ask what happens to a defect found after launch, and get the answer in writing. A partner who answers both clearly is showing you their process. A partner who says they test everything thoroughly has told you nothing.

Certification is worth a mention. ISTQB is the recognised international qualification body for software testers and publishes a structured syllabus for testers to be examined against [18]. It is a reasonable baseline signal that someone has been assessed against a common body of knowledge. It is not a guarantee of quality on your specific product, and plenty of excellent testers do not hold it. Use it as one input, not a filter. Our guide to choosing an app development company in Dubai applies the same logic to credentials generally.

Real client stories

These are anonymised situations from projects we have worked on.

The automation suite that cost more than the bugs. A client came to us with a test automation suite built early in their product's life. The interface had changed several times since, and most failures were scripts breaking rather than the product breaking. Their team had started ignoring the results, which is worse than having no suite at all. We cut it back to a small set of stable checks on the flows that genuinely must not break, and moved the rest to a written manual test plan run before each release. Release confidence went up and QA time went down.

The manual pass that was the right answer. A small business platform with a handful of screens and one release a month was quoted an automation project by another party. On that release cadence, the scripts would have taken longer to write and maintain than the manual runs would ever take to execute. We ran a focused manual test pass instead, with a proper plan and a defect log, and left them with test cases their own team could re-run. Automation was simply the wrong tool for the shape of that product.

The defect that was a change request. A client and their previous developer spent weeks arguing about a reporting screen. The client believed it was broken. The developer believed it did exactly what the specification described. Both were right, because the specification was ambiguous and nobody had defined who decides. Now, on every project, we agree the definition of a defect and the definition of a change request in writing before the build, using examples taken from that client's own product.

How SKIMBOX approaches QA

We would rather settle the contract questions first. We offer a written test plan before testing starts, severity and priority scales agreed with you rather than handed to you, acceptance scenarios written before the build so you are testing what you asked for, and a defect log you keep. We will also tell you when automation is not worth it for your product, because that is the honest answer more often than the industry admits.

A focused test pass on an existing build starts from around AED 4,000. On projects where QA is planned in from the start, we typically see it land at around 10 to 15 percent of the build budget, which is our own observation rather than an industry benchmark. Final pricing depends on scope.

See our product engineering services and app development services, or contact us to talk through what your product needs.

For related reading, see our guides on custom software development cost in Dubai and mobile app development cost in Dubai.

References

[1] ISO - ISO/IEC/IEEE 29119-1:2022, Software and systems engineering, Software testing, Part 1: General concepts. iso.org/standard/81291.html

[2] ISO - ISO/IEC/IEEE 29119-2:2013, Software testing, Part 2: Test processes. iso.org/standard/56736.html

[3] ISTQB Glossary - acceptance testing. glossary.istqb.org/en_US/term/acceptance-testing/1

[4] ISTQB Glossary - regression testing. glossary.istqb.org/en_US/term/regression-testing/1

[5] ISTQB Glossary - exploratory testing. glossary.istqb.org/en_US/term/exploratory-testing/1

[6] OWASP - OWASP Top 10, the standard awareness document for web application security risks. owasp.org/www-project-top-ten/

[7] OWASP - Web Security Testing Guide. owasp.org/www-project-web-security-testing-guide/

[8] W3C Web Accessibility Initiative - Web Content Accessibility Guidelines (WCAG) overview. w3.org/WAI/standards-guidelines/wcag/

[9] W3C Web Accessibility Initiative - WCAG 2 Level AA conformance. w3.org/WAI/WCAG2AA-Conformance

[10] NIST - Planning Report 02-3, The Economic Impacts of Inadequate Infrastructure for Software Testing, published 2002. nist.gov/el/economic-impact-studies

[11] SKIMBOX - Custom software development cost in Dubai, our own commercial figures. skimbox.co/resources/blogs/custom-software-development-cost-dubai

[12] SKIMBOX - Mobile app maintenance cost in Dubai, our own commercial figures. skimbox.co/resources/blogs/mobile-app-maintenance-cost-dubai

[13] SKIMBOX - Penetration testing and VAPT in Dubai, our own commercial figures. skimbox.co/resources/blogs/penetration-testing-vapt-dubai

[14] Federal Tax Authority, UAE - Value Added Tax, standard rate of 5 percent and the AED 375,000 registration threshold. tax.gov.ae

[15] TDRA, UAE - National Policy for Digital Accessibility. tdra.gov.ae

[16] U.AE Official UAE Government Portal - Digital accessibility statement, WCAG 2.1 and 2.2 Level AA as a minimum. u.ae/en/footer/accessibility

[17] Central Bank of the UAE - Rulebook, technology risk and information security requirements for licensed financial institutions. rulebook.centralbank.ae

[18] ISTQB - International Software Testing Qualifications Board, Certified Tester syllabus. istqb.org

Frequently asked questions

How much does software testing and QA cost in Dubai?
A focused test pass on an existing build starts from around AED 4,000. That covers a written test plan, test cases across your core flows, execution on your main browsers or devices, and a defect log with severities you can hand to your developers. On projects where QA is planned in from the start rather than added at the end, we typically see it land at around 10 to 15 percent of the build budget. Those are our own figures, not a market survey. Final pricing depends on scope.
Is software testing just the developer checking their own code works?
No. Testing is a structured set of activities that includes reviewing requirements and code without running anything, designing test cases against agreed requirements, executing them at several levels, and reporting results. A developer checking their own feature is one small part of it, and it is the part most likely to miss what the developer did not think of. The international testing standard describes a full process covering planning, design, execution and reporting, not a single click-through before release.
What is the difference between unit, integration and system testing?
Unit testing checks one small piece of code on its own, usually written by the developer as they build. Integration testing checks that pieces work together correctly, such as whether the payment module hands off properly to the order module. System testing checks the whole assembled application against requirements in an environment close to production. This sequence is the standard structure described in ISO/IEC/IEEE 29119. Each level catches a class of problem the level before it structurally cannot see.
Do we need a dedicated QA person, or can developers test their own code?
No standard mandates a separate QA role, so this is a risk judgment rather than a rule. Developers testing their own units is normal and expected. What it does not replace is independent system-level and acceptance testing, because the person who built something is the worst person to find the assumption they built into it. The more your product touches money, personal data, or a workflow people depend on, the earlier independent testing earns its cost.
What is regression testing and why does it keep coming up?
The ISTQB Glossary defines it as testing a previously tested program after a modification, to confirm that defects have not been introduced or uncovered in parts of the software that were not changed. It comes up constantly because every release risks breaking something that used to work fine. It is also the single test type that most rewards automation, since you run the same checks again on every release for as long as the product exists.
What is exploratory testing and is it worth paying for?
The ISTQB Glossary defines it as a technique where the tester actively controls the design of the tests as they are performed, using what they learn to design new and better tests. In plain terms, a skilled person hunts for trouble without a script. It finds usability dead ends and edge cases no written test case would have thought to check. It is worth paying for as focused, skilled effort on new features, not as a repeated routine check.
Should we automate our tests or test manually?
Automation costs more upfront, because someone has to write the scripts and then keep them working, and it only pays back on checks you run repeatedly. Automate regression suites and the paths that must never break. Keep manual the things that change often, the judgment calls about whether a screen makes sense, and exploratory bug hunting. No authority publishes a numeric threshold for when automation starts paying back, so treat any specific number you are quoted as opinion.
Can automated tests replace a human tester entirely?
No, because they do different jobs. Automated tests repeat the same check reliably and cheaply, which is exactly what regression testing needs. But they only ever find what someone wrote them to look for. Exploratory testing depends on a human adapting the test design in real time based on what they are learning, which a fixed script cannot do by definition. The sensible setup is automation for the repeated checks and human judgment for everything else.
What does performance and load testing actually check?
Performance testing measures how the system behaves under expected and peak use: response times, throughput, and how much memory and processing it consumes. Load testing pushes concurrent users or requests up until something slows badly or falls over. It surfaces problems that only appear at scale, such as slow database queries or connection limits. It will not find a single functional bug. A system can be fast and still give the wrong answer, so the two are separate concerns.
Is security testing the same as penetration testing?
Related, but not the same. Security testing is the broad discipline of looking for ways a product could be attacked. A penetration test is one method inside it, where a tester simulates an attacker against an agreed scope. OWASP publishes the Top 10 list of critical web application security risks and the Web Security Testing Guide, which is the methodology reference most serious testing follows. Penetration testing is scoped and priced differently from functional QA, so treat them as separate lines.
What does accessibility testing check?
Whether people using screen readers, keyboard-only navigation, or with low vision or limited motor control can actually use your product. In practice that means colour contrast, tab order, alternative text on images, properly labelled form fields, and tap targets large enough to hit. The standard is WCAG from the W3C Web Accessibility Initiative, with conformance levels A, AA and AAA. When a contract or policy asks for WCAG compliance, W3C notes it almost always means Level AA.
What is user acceptance testing and who should run it?
The ISTQB Glossary defines acceptance testing as formal testing against user needs, requirements and business processes, to determine whether the system satisfies the acceptance criteria and to let the customer decide whether to accept it. You or users you nominate should run it, against your real business scenarios. Our own recommendation is that those scenarios are written before the build starts. Written afterwards, you end up testing what was delivered rather than what you actually wanted.
Who should write the test cases, us or the development team?
The normal split is that developers write and own unit tests because they know the code, the QA function writes integration and system test cases against agreed requirements, and you or your nominated users run acceptance testing against your own business scenarios. This is common practice rather than a rule set by any standard. The failure mode is assuming the developer covers all three levels. Most do not, and most never said they would, so ask early.
What should be in our definition of done for a feature?
At minimum three things: which test levels must pass, what defect severities are allowed to remain open at sign-off, and what is handed over alongside the code, such as test results and a known-issues log. Agree it before the sprint that builds the feature, not after. It works on my machine is not a definition of done. System tests pass, no open critical or major defects, results delivered, is one you can actually check against.
What is the difference between a defect's severity and its priority?
Severity is technical impact, meaning how badly the thing is broken. Priority is business urgency, meaning what gets fixed first. They move independently. A rare crash in an admin screen nobody opens this month is high severity and low priority. A misspelled company name on the homepage the week of a launch event is low severity and high priority. Define both scales in your contract and say who rates what, because this is where most arguments start.
Who decides whether a bug counts as critical?
Whoever your contract says, so put it in writing before the build. A workable arrangement, and the one we use, is that QA proposes the severity rating because they can see the technical impact, and the product owner and delivery team agree priority together because that is a business call. Without that written down, the classification argument happens exactly when you can least afford it, which is the week before or the week after launch.
If a bug shows up after launch, who pays to fix it?
It depends entirely on what your contract says, so agree it before work starts. The usual structure is a warranty window after launch, commonly thirty, sixty or ninety days, during which genuine defects are fixed at no extra charge. The number matters less than the clause existing and being clear about where the warranty ends and paid maintenance begins. Without it, every post-launch bug becomes a negotiation, and negotiations under time pressure rarely go your way.
What is the difference between a defect and a change request?
A defect is the software not doing what the agreed requirements said it would do, and fixing it is the vendor's responsibility. A change request is new or altered scope, something that was never specified or has since changed, and it is billable as new work. Write both definitions into the contract using examples from your own product, and write down the escalation path for when you disagree. This single clause prevents more disputes than any other.
Our developer delivered with no test plan. Is that normal?
It is common, but it is not good practice. ISO/IEC/IEEE 29119 describes a test process covering planning, design, execution and reporting, and it is written to be tailored to the size of the project, including small ones. A partner who produced no plan, no test cases traceable to requirements and no defect log is not simply working informally. They are working outside the structure the international standard describes, and you have no record of what was checked.
How do we know the developer actually tested the app properly?
Ask for the artefacts a real test process produces: a test plan, test cases you can trace back to specific requirements, a defect log with severities, and a summary report against agreed exit criteria before sign-off. If none of those exist, testing probably meant one person clicking through the feature once. Also ask which test levels they run and who runs each one. A clear answer shows a process. We test everything thoroughly shows nothing.
Is an ISTQB certification meaningful or just a line on a CV?
It is a reasonable baseline signal. ISTQB is the recognised international qualification body for software testers and publishes the Certified Tester Foundation Level syllabus and the ISTQB Glossary of testing terms. Holding it means someone has been examined against a common international body of knowledge. Holding it means someone has been examined against a common international body of knowledge. It is not a guarantee of quality on your specific product, and plenty of excellent testers do not hold it. Use it as one input among several, not as a filter.
What is static testing if no code is run?
Static testing means reviewing artefacts without executing the software: requirements reviews, design reviews, code reviews and walkthroughs. It sits alongside dynamic testing, where you actually run the thing, and both belong in a serious test plan. It matters because an ambiguous requirement caught in a review costs a conversation, while the same ambiguity caught after launch costs rework in code, in data, and sometimes in what users have already learned to do.
We are a small team. Is QA overkill before we have real users?
No standard sets a team size or user count where QA becomes necessary, so this is a judgment about risk rather than scale. The more your product touches money, personal data, or a compliance-sensitive workflow, the earlier structured testing pays for itself. For a low-risk internal tool with a handful of users, a disciplined manual test plan is often enough. What is rarely enough is no written plan at all, whatever the size of the team.
Does UAE law require my app to meet WCAG accessibility standards?
It is confirmed for government platforms. The UAE National Policy for Digital Accessibility sets requirements for government digital services, and the official UAE Government Portal states it is built to meet WCAG 2.1 and 2.2 Level AA as a minimum. For private commercial software generally, we could not confirm a UAE legal requirement in our research, so we are not going to assert one either way. If it affects a contract you are bidding for, take your own legal advice.
Is there any UAE law that requires software testing before launch?
We found no general UAE requirement for private-sector software in our research, and we are stating that as an unconfirmed point rather than a clearance. There is one confirmed exception, and it is narrow. The Central Bank of the UAE requires licensed financial institutions to run annual penetration testing and quarterly vulnerability assessments as part of their technology risk obligations. That applies to CBUAE-licensed entities only, not to software companies or apps in general.
Does VAT apply to QA and testing services in Dubai?
Yes. QA and testing supplied by a UAE provider is a service and carries the standard 5 percent VAT where the supplier is VAT-registered, which is mandatory above AED 375,000 of taxable turnover according to the Federal Tax Authority. When you compare quotes, check whether each figure is stated before or after VAT, because that alone can change which quote looks cheaper. If an overseas supplier is involved, check the treatment with your accountant.
How much of our development budget should go to QA?
No government body, regulator or standards organisation publishes a benchmark for this, so anyone quoting one is quoting an opinion. In our own projects, when QA is planned in from the start rather than bolted on at the end, it typically lands at around 10 to 15 percent of the build budget. That is our observation of our own work, not an industry figure. Bolted on late, it costs more and buys less, because rework is already priced in.
Is it true that around half of a software budget goes to testing?
We would not repeat that figure. It circulates widely and is usually attributed to research that does not actually contain it, and we could not trace it to any credible primary source. There is a genuine government study in this area, the NIST Planning Report 02-3 on the economic impacts of inadequate software testing infrastructure, but it was published in 2002, it is an economy-wide estimate for the United States, and it is not a project budgeting rule.
Is there a published day rate for QA testers in Dubai?
Not from any authority we could find. Standards bodies publish methodology, not prices, and no UAE government body publishes rates for QA work. What exists is what providers publish about their own commercial figures, ours included, and those are quotes rather than surveys. Treat any number presented to you as a market rate with the same suspicion you would treat any other unsourced statistic, and ask what scope of work the figure actually covers.
What happens if we skip QA and just fix bugs as users report them?
Your users become your test team, which costs you their patience rather than your budget in the short term. The general principle, and it is directional rather than a measured multiplier, is that defects cost more to fix the later they are found, because by then the problem is baked into code, into stored data, and into habits people have formed around it. Production bug fixing also arrives without warning, which is the worst way to schedule engineering work.
Do we need a separate QA contract or is it part of the development agreement?
Either structure works and no standard dictates one. What matters is that the same six things are written down somewhere: which test levels are covered, who writes and runs the test cases, the definition of done, the severity and priority scales, the warranty period for post-launch defects, and the change request process. If QA is buried inside a development agreement as one line saying testing included, that line is doing no work at all.
What is the biggest tell that a delivery partner is under-testing?
No documented test plan, no defect log with severities, and testing that turns out to mean the developer clicking through their own feature once before shipping. None of that matches the process structure the international testing standard describes, or the level structure running from unit through to acceptance. A second tell is vagueness about who fixes what after launch. Partners with a real process answer that question in specifics, because they have had to answer it before.

SKIMBOX Team

Tech Consultancy

Want us to build something?

We work with teams across MENA, UK, USA, and India to build products, run programs, and grow.

Get in touch

Continue reading

Software Testing and QA Services in Dubai: What to Agree Before Anyone Writes a Test

Testing is a contract question first

The five things to agree before testing starts

The test types, in plain language

Manual or automated? The honest answer

What QA costs in Dubai

The UAE-specific parts

How to tell whether your partner is actually testing

Real client stories

How SKIMBOX approaches QA

References

Frequently asked questions

Want us to build something?

Continue reading

Customer Loyalty App in the UAE: Why Most Businesses Should Not Build One

Mobile App Maintenance Cost in Dubai: Why Apps Break Without It

How to Choose a Top Mobile App Development Company in Dubai

Capabilities

Pages

Links

Capabilities

Pages

Links

Testing is a contract question first

The five things to agree before testing starts

The test types, in plain language

Manual or automated? The honest answer

What QA costs in Dubai

The UAE-specific parts

How to tell whether your partner is actually testing

Real client stories

How SKIMBOX approaches QA

References

Frequently asked questions

Get fresh writing in your inbox

Want us to build something?

Continue reading

Customer Loyalty App in the UAE: Why Most Businesses Should Not Build One

Mobile App Maintenance Cost in Dubai: Why Apps Break Without It

How to Choose a Top Mobile App Development Company in Dubai