Recommended test environment
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 you customized a CCMS Output Generator file, the next upgrade or update could overwrite the file, impacting its functionality.
Test IXIA TEXTML Server
If you perform an upgrade or update, follow the related instructions in a test environment and note any specific procedures required for your specific deployment before you proceed with validation and implement the changes in the production environment.
If you make changes to IXIA TEXTML Server configuration files, test the changes in a validation environment to confirm that the changes you made apply successfully and no regressions have occurred. For example, determine if fixes that you implemented before the update still work afterwards.
If you made changes to fix a problem, follow the steps you took to reproduce the problem after the modification and confirm that the problem no longer occurs.
Test the docbase
If you made changes to the workflow, follow a 3-step sequence:
- Move the object between states to confirm successful application of the changes
- Confirm that the workflow behaves as expected
- Make sure no regressions occurred
Scenario |
Prerequisite |
Action |
---|---|---|
Rename or remove a status |
Move all objects out of the status you want to rename or remove |
Make the change and follow the identified 3-step process |
Modify a DTD |
None |
Make the change and then lock and release objects that contain new and old content affected by the change to confirm they are still valid |
Small configuration changes |
Make the change and then verify that the changes were applied successfully and no regressions occurred |
Test IXIA CCMS Desktop
Test fixes for resolved bugs or configuration changes by performing actions in the CCMS Desktop, which confirm the fixes or changes behave as expected.
Test Output Generator
For plugins, DTDs, renderers such as XEP, FOP, Antenna House, or a conductor file in the DITA Open Toolkit modifications, generate output on an impacted test map. Confirm successful application of your changes and that no regressions occurred.
To facilitate testing, you should create a test map with topics containing all the edge cases in your content for your exclusive use as you test the IXIA CCMS Output Generator. When you do, you can keep a copy of the approved output from the test map. When you make a change to the CCMS Output Generator, you can compare the new output to the approved version to identify any unwanted changes.
Test Scheduler
To test your changes, create a situation that triggers the desired action so that you can confirm it behaves as expected. For example, you can perform a status change that causes the IXIA CCMS to execute a job trigger.
Test IXIA CCMS Web
Perform regression testing to ensure that all existing functionality still works after implementation of changes.