Software Development Demos, Feedback and Testing

Use demonstrations to follow progress

• A demonstrationThe developer walks through a part of the software and explains what is ready, what is still being built and what needs your input.
• A hands-on reviewYou or a member of staff tries the agreed task and checks whether it works as expected in a realistic situation.

Agree on review dates as part of the project plan. For some projects, a demonstration every two weeks gives people a useful opportunity to see progress. The right interval depends on the work and when decisions are needed.

Ask what you will see before each meeting, so you can bring the right examples and include the people who know that part of the business.

Follow a task from its start to its result

Watch what happens to the information as it moves through the system. In a quoting tool, enter a customer, prepare a quote, change a quantity and check the document the customer would receive.

Look beyond whether the screen looks finished. Check that the right details remain available, the totals are correct and the next person can continue the work without entering everything again.

Some parts may still use sample records or a temporary screen. Ask which parts are working and which are being shown to explain a planned step. A demonstration of progress is not automatically a release-ready system.

Give feedback the developer can act on

• Hard to act onThe schedule does not work properly.
• A clear reportI moved Tuesday’s job to Thursday. The calendar changed, but the driver’s job list still shows Tuesday. Both should show Thursday.

Describe what you were trying to do, what you did, what happened and what you expected. Include a sample record or screenshot when useful, with sensitive details removed.

Record feedback in one agreed place. Mark which issues stop people completing their work and which are preferences or later ideas. This helps the developer address the most useful changes first.

Keep corrections and new ideas visible

A review can reveal a misunderstanding, a fault in the agreed behaviour or an additional feature you would now find useful. Ask the developer to explain which category applies and record the decision together.

If a request adds work, discuss its cost and effect on dates before it is started. You can keep it for a later stage without losing the idea.

The fixed price and hourly guide explains how to agree on changes and keep spending visible under either arrangement.

Have staff try everyday work and ordinary exceptions

The people who will use the software can notice missing steps that are easy to overlook in a meeting. Give them a short set of realistic tasks and time to try them on the devices they normally use.

Include a straightforward task, a changed or cancelled task, and a case where information is missing or incorrect. For systems with different access levels, check that each person can do their work and sees only the information intended for them.

Use an agreed test area and sample records where possible. Check how customer messages, payments or equipment actions are handled during testing so a practice task does not become a real transaction.

Agree on what must be ready for launch

Keep a short record of the results: what passed, what needs correcting, who will check it again and which less important improvements can wait. A task is easier to approve when everyone can see the example used to check it.

Before release, confirm that the essential tasks have been checked, staff can access the system and the plan for records, training and support is ready. Your business review complements technical testing; it does not replace it.

The launch preparation guide covers how to turn that ready-to-use version into a planned start for the business.

Your next step

Choose three tasks for the next review: an everyday job, a change to that job and a situation that usually needs extra care. Agree who will try them and where the results and decisions will be recorded.