What to check before you accept delivered software

The situation

A textile trader in Surat sells sarees and dress materials to around two hundred dealers across Gujarat and Maharashtra. Orders come in by phone and WhatsApp, and the office spends its evenings typing them into the billing software. The trader has commissioned a dealer app: dealers log in, see the catalogue with their own price list, place orders and check what is pending.

The first increment, catalogue and login, has been delivered to a test environment. The team has sent a message saying it is ready for review. The trader opens the app on their phone, scrolls through a few designs, likes what they see and is about to reply "approved".

This is the point where many projects go wrong later. Acceptance is when you confirm that the work meets the specification. When payment follows acceptance, that confirmation carries weight for both sides. A quick look on one phone is not enough, and it is unfair to the team as well, because problems found after acceptance turn into arguments about whether they were ever in scope.

What acceptance means

Acceptance is a comparison between two things: the signed specification and the working software. You are not judging whether you like the colours or whether a new idea has occurred to you. Those are valid thoughts, and they go on a separate list as possible changes. Acceptance asks one question per line: does the software do what this line says?

If it does not, the work is not accepted and it is put right. If it does, you accept that line, even if you now wish you had asked for something different.

Steps

1. Prepare before you open the app

Print or open the specification for this increment. Make a simple sheet with three columns: the requirement, what you did to test it, and the result (passed, failed, or question). Agree in advance who from your side will test. For the dealer app, that should include someone from the office who handles orders every day, and ideally one or two friendly dealers.

2. Test with real data and real devices

Ask for the test environment to be loaded with your actual catalogue and price lists, because sample items hide the problems that real data shows. Test on the phones your dealers really use, which in many cases are mid range Android handsets on patchy mobile data. A catalogue that loads well on office Wi-Fi may crawl on a 4G connection in a small town.

3. Walk through each requirement

Take each line in turn and do exactly what it describes. For example:

• "A dealer sees only the price list assigned to them." Log in as two dealers on different price lists and compare the same item.
• "Out of stock designs show as unavailable and cannot be added to the cart." Mark one design out of stock in the admin and check from the dealer side.
• "Search finds a design by its code or name." Try a few codes, a partial name, and a misspelling.

Record what you did and what happened. Screenshots help.

4. Try the awkward cases

Most defects hide at the edges. Try a dealer who has forgotten the password. Try placing an order with zero quantity, or a very large one. Switch the phone to Hindi or Gujarati if the specification says the app supports those languages. Lose the connection halfway through an action and see what happens. Log in on two phones at once. The aim is fair and simple: to check the situations your dealers will meet in their first week.

5. Check the parts you cannot see

Some requirements are about what happens behind the screen:

• Roles: can a dealer reach any admin page by guessing a link?
• Data: is the order recorded correctly in the back office, with the right dealer, items, quantities and prices?
• Exports: does the daily order export open properly in Excel and match what was ordered?
• Notifications: if the specification says the office gets an alert for each order, does it arrive?

If you are not technical, ask the team to show you these on a call. Senior technical review is part of the engagement, and asking for a walk through is reasonable.

6. Log issues clearly

For each failure, write what you did, what you expected, what happened and on which device. "Search does not work" will cost a day of back and forth. "Searching for code SR-1042 on a Redmi phone returns no result, though the design is in the catalogue" can be fixed quickly.

Keep issues and new ideas apart. An issue is a gap against the specification. A new idea is a change request, which is estimated and agreed separately.

7. Retest the fixes

When fixes come back, retest each failed line and quickly recheck the lines around it, because a change in one place can affect another. Only then mark the increment as accepted, in writing.

What testing will not catch

Testing finds many problems, not all of them. Some issues only show up when two hundred dealers use the app at once, or in a month with unusual orders. That is why it helps to know, before you sign, what support applies after acceptance. Any warranty or bug fix period is set out in your specification or agreement, so read that part as carefully as the feature list.

Your review also takes time. For an increment like this one, set aside at least half a day for the main tester, plus an hour or two for one or two dealers. If you cannot find that time, say so and agree a later review date. Approve only what you have tested.

Finally, if a requirement in the specification turns out to be ambiguous, both readings may be fair. Talk it through. The usual fix is to clarify the line in writing, then build and test against the clarified version.

A short checklist

Before you accept an increment, check that:

• You tested against the signed specification for this increment, line by line.
• Real data was loaded and real devices were used.
• The people who will use the system took part.
• Edge cases were tried: wrong inputs, lost connection, forgotten password, other languages.
• Roles, stored data, exports and notifications were checked, with a walk through if needed.
• Every issue was logged with steps, expectation, result and device.
• New ideas were recorded separately as possible changes.
• Fixes were retested along with the lines around them.
• You know what support applies after acceptance under your agreement.

For the full picture of how review, acceptance and payment connect, see pay after acceptance.