Every software development proposal has a line that says "testing" or "QA", and it usually looks the same from every vendor. But behind it can sit very different work: a developer clicking through a few screens before handing over, or an organised process with scenarios, devices and a separate environment. This guide is a scope guide for the buyer: how to break the word into parts, how to divide responsibility, and what to require in writing. It is not a guide for people building test automation, and it does not compare vendors.
If you want to understand how testing affects pricing in general, start with the app development cost guide — it breaks down the cost drivers, and testing is one of them. What it costs to build an app — the cost drivers
The six kinds of testing hiding behind the word
Not every kind of testing is needed in every project. What matters is that the proposal says which are included — and which are not, explicitly.
| Type | What it checks | Question to ask the vendor |
|---|---|---|
| Manual testing | A person goes through the system as a user and checks it does what was defined, including unusual states | Who does it — someone who did not write the code? Against which scenarios? |
| Automated tests | Code that checks code: it runs on every change and warns when something breaks | Which parts have automated tests, and are they delivered to you with the code |
| Regression | A check that a new feature did not break something that worked before | How is this verified in each release — manually, automatically, or not at all? |
| Real devices and browsers | That the system works on the devices, OS versions and browsers your audience actually uses | What is the list of devices and browsers, and who set it |
| Load and performance | How the system behaves when many users or a lot of data arrive at once | Is it included at all, and if so — against which load, defined in advance |
| Acceptance testing (UAT) | You, or business representatives, confirm the system does what you ordered — against agreed criteria | How long do you have to test, and what happens if defects are found |
To see how this looks on our side: the mobile app development page describes testing on real iPhones and Androids, across OS versions and resolutions, as part of the project scope — with the exact device matrix set by your audience. What is included in app development — including real-device testing
Who is responsible for what: vendor versus client
Testing is shared work, and most problems appear when each side assumes the other is doing a part. The following table is a starting point for a conversation — not a fixed split. What matters is that it is written down.
| Activity | Usually on the vendor | Usually on the client |
|---|---|---|
| Writing test scenarios | Technical scenarios and edge cases derived from the specification | Real business scenarios: what daily work looks like, and which problem cases happen at your company |
| Running during development | Internal tests, automated tests and QA before each handover | Trying every build shown to you, on time, and giving written feedback |
| Environment and test data | Setting up and maintaining staging | Representative test data, without real personal data that is not approved for use |
| Logging defects | A tracking system, and handling by an agreed priority order | Clear reports: what you did, what you expected, what happened, a screenshot |
| Acceptance | Showing what was done and what remains open | The decision: approve or return — in writing and by the agreed date |
What goes in the testing clause — and what does not
A testing clause you can work with contains a clear list of what is included and a separate list of what is not. The second list matters just as much: it prevents the "we thought that was included" conversation after launch.
- The types of testing included, per the first table, including what is explicitly excluded (for example: load testing).
- The list of platforms: devices, OS versions and browsers the system is tested on.
- The division of responsibility, as in the second table.
- The acceptance criteria for every stage or feature, or a commitment on when they will be written and who approves them.
- The environment: whether there is a staging environment, who can access it, and what data it holds.
- The definition of a "defect" versus a "new request", and a defect-fixing period after handover — as a written agreement, not an oral understanding.
When comparing proposals, this clause is one reason a cheaper proposal is not necessarily cheaper: sometimes it simply includes less testing. How to align scope across proposals and what else to ask a vendor is in the guide to choosing a software house. How to choose a software house — and what to compare between proposals
Written acceptance criteria
An acceptance criterion is a sentence you can answer "yes" or "no" to after trying the system. It derives directly from the requirements — which is why a well-formed requirements document is a precondition for good criteria. If you are still before that document, the example in the requirements-document guide shows what a requirement at screen level looks like. An example of an app requirements document
| Instead of | Write | Why it is better |
|---|---|---|
| "Registration will work" | "A new user entering valid details receives a confirmation and lands on the home screen; a user entering an already registered email sees a message explaining it, not a generic error" | It can be tried and answered yes/no, and includes an error state |
| "The system is fast" | "The list screen loads and shows results within a time agreed in advance, on the devices on the list, on a normal connection" — with the time set between the two parties, not copied from here | Turns a feeling into something measurable |
| "Appropriate permissions" | "A user in role X cannot see or open data belonging to a user in role Y; trying a direct link returns a no-permission message" | Also checks the case where the user "tries to bypass" |
A staging environment: where testing happens
Staging is a copy of the system intended for testing: the same configuration as the live environment, but with test data and no real users. Without it, testing happens either on the developer's machine — where everything "works" — or on the live system, where a faulty test can send a message to a real customer or change real data.
| Question | Why it matters |
|---|---|
| Is there a staging environment separate from the live one? | Without separation, every test is a risk to the live system |
| Can you access it yourselves? | Acceptance testing done only in the vendor's demo is a demo, not acceptance |
| What data does it hold? | Representative test data allows real scenarios to be tested without exposing customer information |
| How does it connect to external services (payments, SMS, email)? | Connecting a test environment to a real service may charge money or send messages. Ask the external provider whether it has a separate test mode |
| Who pays for the environment and who holds access to it after handover? | An environment that stays with the vendor leaves you with nowhere to test future changes |
A marked example: a testing clause in a proposal
| Item | Example wording |
|---|---|
| Included | Manual testing of every feature before each handover; automated tests for the core business logic; regression before each release; testing on the devices and browsers in the attached list |
| Not included | Load testing (can be added as a separate stage based on expected user volume); external penetration testing |
| Vendor responsibility | Technical scenarios, execution, defect logging and fixing, staging setup |
| Client responsibility | Business scenarios; acceptance testing of each build within ___ working days of delivery; approval or return in writing |
| Acceptance criteria | Written for every feature before its development begins and approved in writing by the client |
| After acceptance | A defect found within ___ after handover that contradicts an approved criterion is fixed at no extra charge; a change to approved behaviour is a new request |
What happens when testing missed something
Testing reduces risk; it does not remove it. Something will always be found after launch, so it is important to know in advance what happens then. A good agreement covers who receives the report and how, how severity is graded (a defect that blocks work versus a cosmetic one), and under which framework fixes are made — within a defined fix period or under a maintenance agreement. The software development page describes a bug after launch as not the end: someone handles it, within the scope and hours set in the maintenance agreement. How a software project is defined and delivered — including acceptance criteria per stage
What we do at this stage
Our service pages describe a defined scope delivered in stages with acceptance criteria for each stage, and testing on real devices in mobile projects. If you hold a proposal and are unsure what its testing clause includes — from another vendor or from us — you can bring it to a conversation and go through it using the tables in this guide. Custom software development — definition and delivery