Skip to main content
Kinetic Community

Testing & Deployment

Document Overview

The following document will outline testing and technical deployment strategies for a Kinetic Request implementation. 

Testing

Your service catalog is likely to be used by many employees or customers during the duration. Creating good requirements documents, as outlined in this Delivery Model, can be invaluable during testing. 

Some tips on testing:

  • Someone other than the form author(s) should test the functionality.
  • Requirements documents and the process diagram flow make good test plans/scenarios. The use cases developed during requirements gathering can often be directly translated into test plans.
  • Test from the requestor and approver’s point of view.
  • Test every possible scenario. This is particularly important for trees that have approvals or logical branches within the tree. Be sure to include all approval responses, including allowing approvals to expire, and all logical branches of the tree. Referring to the process diagram is helpful here.
  • Notifications:  Did they get sent out to all the correct people in the process?  Was the email message text correct?  Referring to the process diagram is helpful here.
  • What does a user see if something incorrect happens, such as trying to access an already-approved request?
  • If a record is supposed to be created (such as in Incident or Change), make sure to test field lengths, required fields and other requirements that the destination application has.
  • Is the look/feel consistent to the user throughout the process?

Development to QA to Production

At minimum, a development and production environment should be in place for Kinetic Request, with a third QA/Testing environment preferable.  This allows new service items to be created and existing ones modified without affecting those already in use.  This also allows a place for users to create test requests without adding test/dummy data into a production environment.

Kinetic Request includes a migration utility to move a form from one server to another. 

The process is typically:

1.      A form author exports a zip file of your existing form, using the web-based Kinetic Request export utility.

a.      This zip file includes all of the related Remedy data associated with a form definition.      
b.      The data is exported in Remedy XML data export format.
c.      A text file is also created in the zip that includes the name of the form exported, the date, the ID, and a count of records of each of the form data exported.

2.      This zip file can then be included in any release/change process documentation required.
3.      At a later time, the person implementing the change will import the zip file using the web-based Kinetic Request import utility.

a.      For new forms, the utility simply imports the data
b.      For existing forms, the utility compares the data in the import to the existing form with what resides on the server to determine what form elements need to be added, modified or removed and then performs the appropriate operations.

You can also use KURL to move a catalog, service items, bridges, etc. from one environment to another. This presentation goes over some of the use cases for KURL. Note that KURL does not preserve instance IDs between environments.

Migrating other components

There are times when other components, besides the service item form itself, need to be migrated.

Message Templates

Message templates can apply to one or more forms, and are often shared between many. Because of this, exporting the message templates when exporting your form (via the export message templates check box) is often not advisable, particularly if this is an existing form.  Exporting message templates will export ALL of the message templates within the service catalog.

Therefore, for new message templates:  To export/import message templates the conventional Remedy method: Via the User Tool for export and Remedy Import tool (for new messages). 

For existing message templates, the easiest method is often to just manually make any changes in all of your environments. However, it is very important to keep your message templates in sync between your servers (not only the names but the underlying instanceIds/GUIDs).

Examples: 

You create a new message template in dev:  Export the message template(s) from dev using the User Tool.  Import into QA/Production using the Remedy import tool (making sure to create new Request Ids, rather than updating).  The instance Ids for the message templates will be the same between servers.

You update one of these message templates:  Manually make the same update in QA/Production via the “Message Templates” link on the Service Catalog Console. 

Service Catalog Definition

When you export a form, you have the option of including the service catalog definition with the form.  The first form that is migrated from a catalog should include the service catalog definition.  Importing a form onto a server without the catalog first in place will give an error. 

Subsequent form imports do not need to include the service catalog definition.  However, if the catalog has changed (new categories added, for instance), re-export the definition.

Other Items

Any core code changes will need to be moved manually.  These could include:

  • Customized JSP files
  • Remedy Filters or other Remedy workflow

Bridges and datasets can be migrated using KURL.

Supporting data may need to be moved as well. How this would be moved will depend on the system this data is stored in (Remedy, AD, etc).

    Previous (Building_A_Portal)