The following document will outline testing and technical deployment strategies for a Kinetic Request implementation.
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 json file of your existing form, using the web-based Kinetic Request export utility.
a. This json file includes all of the related data associated with a form definition (security policies, etc).
2. This json 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 json 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.
Any core code changes will need to be moved manually. These could include:
- Customized JSP files
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).