Structural (Non-functional) Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 126

there is no sign of smoke, the engineer starts using the equipment. The software
smoke test is not exhaustive like regression testing. Rather, it is an attempt to verify
the usability of the most likely fi rst production confi gurations independent of the
confi guration test cases that were executed during software development.
8.6 ADMINISTRATIONTESTING
Administration of a new application or system is the next operational step after
successful installation and smoke test. Administration can include such technically
complex activities as applying updates and fi xes to the software. Administration
can also include organization-specifi c activities such as adding users to the system,
adding user security to the system, and building master fi les (customer lists, product
lists, sales history, and so forth).
Administration testing is an extension of functional testing of business activities
to functional testing of business support activities. If the administrative software
components are developed fi rst, then the results of successful administrative tests
can be saved as the starting point for business function testing that relies on cor-
rect administrative setup. If the administrative components are developed second to
business functions, then the manually built system setup fi les used to successfully
test the business functions can be used as the expected results of the administrative
component tests.
8.7 BACKUP AND RECOVERY TESTING
Sooner or later, all business software applications fail. The extent of fi nancial dam-
age that occurs with this failure is directly proportional to the software developer's
effort to minimize that fi nancial damage. If little thought is given to recovery after
failure, the business will not be able to recover. A surprising number of commercial
software packages simply instruct you to “start over” when a failure occurs.
If serious thought is given to recovery after failure, a backup strategy emerges
that enables that recovery to occur. The accepted approach is that you start your
failure defense by periodically making backup copies of critical business fi les such
as master fi les, transaction fi les, and before/after update images. Then, when (not
if) the software fails, the backup fi les are used to restore the software close to its
pre-failure state.
Depending on what resources you are willing to spend on routine backup ac-
tivities, the recovery pre-failure state can range from last weekend's backups (fairly
inexpensive) to last night's backups (more expensive) to all backed up transactions
except the one that caused the failure (very expensive but guarantees minimum loss
of business). To test backup and recovery processes, you must perform a number
of backups, interrupt the application abnormally, and restore the application using
just the backups. Recovery data are then validated against the expected pre-failure
state.