Software Testing Explained for Clients: What a Professional Team Should Be Doing

When you pay for software, you see screens and features. You mostly do not see the testing, which is why it is the first thing cut when a schedule slips or a quote needs to look smaller. The cost arrives later: bugs in production, releases that break things that used to work, and a team that is nervous about changing its own code.

This guide explains, in plain terms, the kinds of testing a professional team should be doing on a custom software development project, so you can tell a real testing practice from a line called "QA" at the bottom of a proposal.

Why testing is part of the build, not a phase at the end

Older project plans show testing as a block at the end: build for months, then test for a few weeks. The weakness is timing. Problems are found when the developer who wrote the code has moved on to something else, when other features have been built on top of the faulty one, and when the deadline is close. That final block is also the part of the plan that gets squeezed when earlier work runs late.

Professional teams test as they go. A developer writes automated tests alongside each feature, those tests run automatically every time anyone changes the code (a practice called continuous integration), and a feature is not counted as done until the tests pass and a person has tried it. Testing is part of the definition of finished work, not a department that receives the work afterwards.

Unit, integration and end-to-end tests

A unit test checks one small piece of logic in isolation, such as the function that calculates sales tax or VAT on an order. Thousands of them can run in seconds. An integration test checks that pieces work together: your code and its database, or your application and a payment provider's API. An end-to-end test drives the whole application the way a user would: open a browser, log in, add an item to the cart, pay. It is the closest to real use, and also the slowest and the most likely to fail for reasons unrelated to a real bug.

That trade-off is why Google's testing team argued for a pyramid shape: many unit tests, fewer integration tests, and a small number of end-to-end tests, with the exact mix varying by team.

Together these tests do the job of regression testing. A regression is something that worked last month and stopped working after an unrelated change. Re-running the full set of tests on every change catches it before your customers do, and that is the largest practical payoff of automation.

Automated versus manual testing: what each is for

Automated tests are good at checking the same known behavior again and again without getting bored or skipping steps. Their limit is that they only check what somebody thought to write down.

Manual exploratory testing covers the rest. A skilled tester uses the product without a script and tries to break it: pasting a very long name into a form, double-clicking the pay button, pressing Back halfway through checkout, losing signal mid-upload. This finds the problems nobody anticipated, and it also finds things that technically work but confuse people.

A workable rule: automate what must keep working, and use people to find what nobody predicted. When a person finds a bug, a good team adds an automated test for it so it cannot quietly return. User acceptance testing, where you confirm the software does what your business needs, is a separate step that belongs to you. It does not replace the team's own testing.

Performance, security, accessibility and device testing

These check qualities of the system rather than individual features. They are often left out of a quote unless you ask.

Performance testing

This measures how the system behaves under realistic and peak load: how fast pages respond, and what happens when many people use it at once. It only works if you supply honest expectations about user numbers and busy periods.

Security testing

This looks for weaknesses an attacker could use, such as one customer being able to view another customer's records. Testers commonly work from the OWASP Web Security Testing Guide, a free and openly published reference. Automated security checks during the build are different from an independent penetration test before launch; systems that handle payments or personal data usually warrant both.

Accessibility testing

This checks that people who use screen readers, keyboards only, or enlarged text can use the product. It is usually measured against the W3C's WCAG 2.2, which defines three conformance levels: A, AA and AAA. The W3C is explicit that no tool alone can determine whether a site meets accessibility standards and that knowledgeable human evaluation is required. Whether a particular standard is legally required of you depends on your sector and on whether you operate in the US, the UK or both, so take proper advice. This article is not legal advice.

Device and browser testing

Software that works in Chrome on a developer's laptop can still fail in Safari on an iPhone or on a small Android screen. Agree a written list of supported browsers, devices and operating system versions at the start, ideally based on what your own customers use.

What test coverage does and does not tell you

Test coverage is the percentage of the code that is executed when the automated tests run. It is easy to misread.

Coverage reliably shows which parts of the code have no tests at all. It does not show whether the tests check anything meaningful, because a test can run a piece of code without verifying its result. Martin Fowler, a widely read writer on software design, puts it this way: coverage is useful for finding untested parts of a codebase and "of little use as a numeric statement of how good your tests are." He adds that high numbers are easy to reach with low-quality testing. So ask what is covered, not only how much. Are payments, permissions and financial calculations tested thoroughly?

What testing means for cost and speed

Testing adds effort up front. Writing automated tests takes developer time, and that time should be visible in the estimate. A quote that is far cheaper than the others may simply have left it out. How much testing is reasonable depends on a few drivers: what a failure would cost you (money, personal data, safety), how many external systems are integrated, how many devices and browsers are supported, and how long the software will live and how often it will change. More on these in our guide to custom software development cost drivers.

On speed, the first weeks are slower and later months are faster, because the team can change code without manually rechecking everything. A throwaway prototype built to test an idea needs far less testing than a system that takes payments.

Common mistakes to avoid

• Treating testing as a separate line item that can be negotiated away to hit a price.
• Relying only on manual testing, so every release needs days of rechecking and releases become rare.
• Tolerating tests that fail at random, which teaches the team to ignore failures.
• Testing only the ideal path, where the user does everything correctly and nothing times out.
• Leaving performance, security and accessibility until the week before launch.

What to do next: questions to ask a development company

Before you sign, put these questions to each company you are considering. Good answers are specific and name tools, people and routines.

• Do developers write automated tests as part of each feature, and is that time in the estimate?
• Do the tests run automatically on every change, and can a change be released if they fail?
• Who does exploratory testing, and on which devices and browsers?
• Which of performance, security and accessibility testing are in scope, and which are not?
• Will I receive the tests along with the source code, and can I see the results during the project?

Conclusion

Good testing is a set of habits that runs through the whole build: automated unit, integration and end-to-end tests that guard against regressions, people who explore the product looking for what nobody predicted, and specific checks for performance, security, accessibility and real devices. What matters is not a coverage number but whether the parts that would hurt you most if they failed are tested well.

Entrant Technologies builds websites, web applications, mobile apps and custom software. If you would like the testing scope written out clearly in an estimate for your project, you can request a quote and ask us the questions above.