SoftwareTesting:SoftwareUpdateTesting

(write me)

I like to think in terms of risk, both the risk of something going wrong, and the cost if something does go wrong.

I can think of three separate systems involved in the overall software update process (and there might be more):

1. build system that generates the update and install files
2. servers that deliver update information and update files to client
3. client update process which queries for, receives, and applies the update files.

And I've heard about the following problems that occurred in the past:

• build system generated update file that removed everything
• server ran out of space, resulting in zero-length update file. Client looped trying to update.
• client-side update log file not created correctly
• update of legacy installation resulted in inconsistent state, causing odd problems

My proposed strategy for software update automated testing is as follows:

• add simple scripts to the build system to sanity-check the update files

The chance of generating bad update files is small, but the cost should that happen is huge.

--Davel 10:22, 24 Jan 2006 (PST)