| Article Index |
|---|
| Website testing: testing before a new release |
| Page 2 |
| All Pages |
Verify
INI, Property Files, or Other Configuration Files
A
combination of property files and INI files are often used for configuration
settings that are specific to the environment. These files define where content
and graphics are being read from, session timeout values, error file locations,
etc. Since the system test environment is not configured the same as our
production environment, these configuration files must be carefully checked
with each release and for each server. You should have scripts in place that
the network staff uses which forces the files to be in sync from one server to
another, but still take the time to at least spot-check the configuration files
on each production server. Similar to the visual checkpoints, build a list of
any configuration file changes for the release in advance. This list is used by
the network staff who modify the files and by quality assurance, so everyone on
the team is reading from the same document.
Specific
Checkpoints for Specific scenarios
Sometimes
a change is made that impacts certain aspect of the site that are worth
checking in production. For example, a required field is added in online
registration that won’t work correctly unless the corresponding database
modification has been made. If needed, create accounts in advance for this type
of testing. If your database design is complicated or includes triggers, stored
procedures, etc., you might want to enter the first few orders or records and
check the data in the database before your site goes live.
Go
Live
Once
these checkpoints have been made and everyone on the team is confident the
build is ready, go live. Be ready to receive the user email notification
indicating that the site is now online, and then return to your test lab to
check how the site is being presented outside the firewall.
Steps to Verify the
Release is Working When the Site Is Live
Verify
the First One or More Records in the Database
If new
tables have been added to the database or major changes have been made, the
first few records in the production database are checked by the DBA and QA team
to ensure the data is accurate.
Verify
Any Third-Party Links
You might
have a couple of links that work with other companies and their Web sites. When
your site goes live, check to see if these links are working to ensure the
sites are working together as defined. Check them from both inside and outside
of our firewall.
Check
that Nightly or Weekly Jobs Are Ready for the Environment
Last on
the list should be checking of any nightly or weekly jobs that need to be run
in production have been modified and are in place. Typically, DBA will check to ensure data warehousing
jobs and other jobs are in place and configured correctly. Following the
release, the team should keep an extra eye open for any production issues. The
technical support team—which must be told in advance of each release—also waits
to hear if any issues arise. If so, the release team is immediately called into
action.
Conclusion
Preparing
a checklist in advance helps minimize time and confusion during the release
cycle. This is especially helpful if you have to complete the release cycle at
three or
Subscribe to this comment's feed
| < Prev | Next > |
|---|
