Testing after modifications
How you test a modification depends on the component and type of modification you made.
Always implement and test modifications on a test environment before attempting them on the production environment. As you work on the modification, document your procedure so you can follow it when you test the procedure in a validation environment and then implement the changes on the production environment. Check logs for warnings and errors. Making untested changes directly in the production environment is not recommended since it may cause serious unwanted effects or render the environment unusable.
Any customized solution you have built on any of the components should be tested after each modification, upgrade, or update. Changes made as a result of the modification, upgrade, or update may inadvertently break the custom solution.
For example, if an IXIASOFT file was changed while implementing a customized functionality into the Output Generator, the IXIASOFT file may be overwritten when the next upgrade or update is performed, which may cause the functionality to break.
Testing IXIASOFT TEXTML Server
If you are performing an upgrade or update, follow the instructions in a test environment and note the specific procedures needed for your deployment before proceeding with validating and implementing the changes in the production environment.
If you made changes to IXIASOFT TEXTML Server's configuration files, test the changes on a validation environment to confirm that the changes were applied successfully and no regressions have occurred (for example, are fixes that you implemented in the past are still working after the upgrade or update?)
If the changes were implemented to fix a problem, follow the steps to reproduce the problem and confirm that the problem no longer occurs.
Testing the docbase
If you made changes to the workflow, move the object between states to confirm that the changes were applied successfully, the behavior is as expected, and no regressions have occurred.
If you made changes to a DTD, lock and release objects containing new and old content affected by the DTD changes to confirm they are still valid.
If you made small configuration changes, verify if the changes were applied successfully and no regressions have occurred.
Testing IXIASOFT CCMS Desktop
Test fixes for resolved bugs or configuration changes by performing actions in the CCMS Desktop which confirm the fixes or changes work as expected.
Testing Output Generator
Test changes to the plugins, DTDs, renderers (such as XEP, FOP, Antenna House), or a conductor file in the DITA Open Toolkit by generating an output that should be affected by the changes you made and confirm that they were applied successfully and no regressions have occurred.
To facilitate testing, it is recommended that you create a test map with topics containing all the edge cases in your content for your exclusive use for testing the IXIASOFT CCMS Output Generator. You can then keep a copy of the output from the test map as your 'Approved Output'. When you make a change to the CCMS Output Generator, you can compare the new output to your Approved Output to identify any unwanted changes.
Testing Scheduler
Test your changes by instigating a situation to trigger the action so you can confirm that the behavior is as expected. For example, you can perform a status change that causes the IXIASOFT CCMS to execute a job trigger.
Testing IXIASOFT CCMS Web
Perform regression testing to ensure that all existing functionality still works after the changes were implemented.