“Software bugs are like cockroaches; there are probably dozens hiding in difficult to reach places for everyone you find and fix.”

― Donald Firesmith

It is important that you and your developer need to test the deliverable from each sprint. The criteria for these tests are specified by you, the customer, and agreed to by the developer.

All the tests have to be brutal and thorough. It might seem harsh, but you can’t assume that anything in the app works right while you’re testing. Don’t leave any stone unturned and push all the app’s features to their limits.

It’s a good idea to keep a library of the different tests that you run with every new deliverable. Since many of these deliverables directly affect others, you should rerun some, maybe all, tests on past deliverables. It’s up to you and your developer to discern which tests merit redoing, based on which old deliverables you think the newest one affects. There’s always the chance that these latest changes have caused some other features in the app to break. It’s better to catch these bugs sooner rather than later.

A series of steps for testing follows:

1. Create a spreadsheet document listing the tests that you’ll run. Group these tests by category (feature, page, etc.) Then share this document with your developer using Confluence, Google Docs, or whichever method’s most convenient.
2. Think from the perspective of a potential customer. How would an average person find this app? Beautiful or gaudy? Easy or too complex? Are there any features they’d think are useless? Are there any features that are glaringly missing?
3. Use multiple devices to test the app, if you can. The app could produce different results when run on different hardware.
4. For every new test run of the app, you and your developer should save a corresponding version of the spreadsheet, with results from that version’s tests.
5. Your app needs to pass every test in your spreadsheet.

After testing, nothing that’s in this app should be a surprise to you. If there are any bugs or features that shouldn’t be there, you need to discuss with your developer what to do about these errors.

Collaborative effort with your developer saves you time and money that you can use to make your app work for you.

Next time: Different Business Models