Software Testing Basics for Delivery Teams

Software testing is the work of checking that software does what it should, and does not do what it shouldn't, before real users find out the hard way. For delivery teams that ship to clients, testing is also a promise: when you say a feature is ready, someone has actually checked it.

You do not need a huge QA department to test well. You need clear types of testing, clear owners and a record of what happened.

The main types of testing

Different tests answer different questions. Most teams use a mix.

• Unit tests — developers check small pieces of code in isolation, usually automated.
• Integration tests — check that components work together, such as the app and its database.
• Functional testing — a tester checks a feature against its acceptance criteria.
• Regression testing — confirms that new changes have not broken existing behaviour. Our guide to regression testing goes deeper.
• User acceptance testing — the client or end users confirm the software meets their needs.

Automated tests catch a lot, but they only check what someone thought to write. Manual testing by a person still finds the confusing screen and the edge case nobody predicted.

Who should test what

A useful rule: the person who built it should not be the only person who tests it.

1. Developers own unit and integration tests and do a quick check before handing over.
2. A named tester checks each ticket against its acceptance criteria.
3. The client confirms the delivered work meets the brief.

Naming the tester on the ticket matters. "Someone will test it" usually means nobody does.

Need proof your work was tested? See how Flow records test runs and sign-off as evidence. Get started with Flow →

Organise testing into runs

Ad-hoc testing is hard to trust. A test run gives it shape: a defined set of tickets, assigned testers, a start and finish, and a recorded result for each item.

A simple test run looks like this:

1. Choose the tickets that are ready to test.
2. Assign testers.
3. Start the run and test each ticket.
4. Mark each one pass or fail, logging an issue with screenshots for every failure.
5. Complete the run and review the results.

We walk through this step by step in how to run a test run.

Do you need a dedicated tool?

TestRail is a well-established, dedicated test-management tool with rich test case libraries, plans and reporting. For teams with large, formal test suites it is a strong option. For many delivery teams, though, the friction is jumping between a tracker and a separate testing tool, then copying results back. If you are looking for a TestRail alternative, consider whether your testing could live alongside your tickets instead.

How Flow helps

Livex Flow builds testing into the same place your tickets already live.

• Testing hub and test-run wizard. Pick a project, choose the tickets and assign testers in a few steps.
• Runs with real timings. Start, pause, cancel and complete runs, with time recorded.
• Pass or fail per ticket. Record results, amend them if needed and see each ticket's failure history.
• Issues with evidence. Log issues with attachments during a run, with drafts auto-saved so nothing is lost mid-test.