Testing What Matters Most in Our Software

Every team has limited time for testing. Spend it evenly across every line of code and the critical paths get the same attention as a footer link. Spend it wisely and the parts that would hurt most if they broke are checked most carefully.

We focus our testing on what matters most to the people who use our software. Here is how we decide what that is, and how different kinds of checks fit together.

Start with the cost of failure

The first question about any feature is: what happens if this breaks? The answer sorts features into rough tiers:

1. Severe and hard to undo. Payments, refunds, account access, permissions and anything that could show one organization's data to another.
2. Severe but recoverable. Publishing, imports, backups and email sending, where a failure is serious but can usually be repaired.
3. Annoying. Layout glitches, slow pages and confusing messages.
4. Cosmetic. Minor visual inconsistencies.

The first tier gets the most thorough testing, including tests that try to break the rules on purpose. Lower tiers get lighter checks proportional to their risk.

Test the rules, not just the happy path

For high-risk areas, the most valuable tests are the ones that try what should be refused. Can a member open the admin area? Can an editor delete something only administrators may delete? Can one account's search find another account's members? Can a duplicate payment confirmation credit a wallet twice? Can an unregistered AI call spend money?

Each of those tests encodes a promise. When one fails, it is not a minor regression; it is a broken promise caught before a customer finds it.

Focused tests over sprawling ones

A test that checks one behavior clearly is easier to understand and fix than a test that checks twenty things at once. When a focused test fails, its name tells you what broke. We prefer many small, specific tests for important rules over a few huge tests that fail mysteriously.

Automated tests have limits

Automated tests are excellent at checking logic: calculations, permissions, data rules and service behavior. They are less good at judging whether a page looks right, whether a workflow makes sense to a real person or whether an outside provider behaves the way its documentation says.

So we pair automated tests with other kinds of evidence. Our pipeline checks that the platform builds, migrates and responds after each release. Signed-in checks in a real browser confirm that features work for a person. Provider and financial checks confirm that real outside services and real money behave as expected. Each answers a different question, as described in signed-in browser checks before we call a feature accepted.

Some checks belong on the real system

Certain features depend on real infrastructure in ways that local test setups cannot imitate well, such as how the content system behaves with real customer data or how pages render behind the real network setup. For those, we verify on the deployed platform with a dedicated quality-assurance account and real, authorized test data, using read-only checks or careful, reversible actions. Those checks are recorded separately from automated test results.

Fixed bugs become checks

When we fix a bug, we ask whether a test could have caught it. Where practical, the fix includes a regression check, so the same bug cannot quietly return. You can read more in turning fixed bugs into regression checks.

Choosing when to run the full suite

Running every test on every small change slows a team down. Our pipeline lets each push choose a fast run or a full run, while always keeping the release safety checks. Changes to money, permissions, data rules or shared services always get the full suite. That balance is explained in fast runs and full runs.

Frequently asked questions

What should be tested first in a web application?

Start with what would hurt most if it broke: payments, permissions, account access and data separation between customers.

Are automated tests enough?

No. Automated tests check logic well, but real browser checks and provider checks are needed to confirm features work for people and with outside services.

Why test things that should fail?

Tests that confirm forbidden actions are refused protect the most important rules, such as who can see or change which data.