Case Submittal Best Practice Calypso Help Desk Case Submittal Best Practice Product Support October 2013 1 © 2010 Calypso Confidential

Agenda HD Case Preparation: Do’s HD Case Preparation: Don’ts How to report an issue How to create a supporting test case

HD Case Preparation: Do’s Always provide a clear and complete description of the issue on the HD template: Make sure that the System configuration, Calypso Version, Client Contact, etc., are correct and up to date. Identify the effected environment (Production, UAT, Development etc.) concerned, before raising the issue to Calypso. Systematically try to replicate in your ‘test environment’ free from custom code.

HD Case Preparation: Do’s No matter how simple the bug, always: attach a test case with screenshots of config and steps to replicate (see example on following slides). It avoids making assumptions, reduce the turnaround time and ensure to receive a resolution as per expectations. Prepare your test case as if the person who will read it knew nothing about your issue and the background. The test case needs to “tell the story clearly and explicitly”

HD Case Preparation: Do’s If the issue deals with a specific module (ERS, Data Uploaders, Clearing, etc.) clearly mention the Module version used Clearly specify what part of the observed results is not acceptable or buggy and: what should be the expected results? (i.e. value ranges etc.) Always, raise “one issue” per case, avoid listing a bunch of issues on a given product, feature or module. Keeping single issue related HDs ensure proper measurement of the progress on each issue and avoid issues to be left over. Login a P2 only if you have intention to deploy the hotfix delivered.

HD Case Preparation: Don’ts Do not submit incomplete HD cases expecting to complete them later on, instead use the “Save As Draft” feature, and only submit your HD case when it is complete (description, test case and logs if needed) Do not submit HD cases with “Description”, “Expected Results” and “Actual Results” as: “See test case attached”. The test case never replace these fields, it illustrate them only.

HD Case Preparation: Don’ts Do not suggest code changes. Always explain the functional implications and the resolution expected. Calypso Engineering is the sole responsible for changing Calypso core code. Never attach source code whether it is belonging to the Client or Calypso. These are governed by the proprietary rights and sharing them would be in breach of those rights. Note: Submitting incomplete HD cases will result in “case rejected” re-submit when all data is available.

How to report an issue Describe the issue as clearly and simply as possible The test case should include the minimum number of trades, data and scenarios as possible to reproduce the problem. A filter with many trades makes analyzing and narrowing down the cause of an issue much more complicated. If an issue appears randomly, simplify the test case until the issue can be reproduced consistently. If the issue on your test case involves a module or modules, please mention the versions on the HD. The Steps to Replicate ( see building test case, next slide) should list each step you are taking to replicate the issue on your side There are cases where the order of the steps taken might affect the results produced and result in the analyst not being able to reproduce the issue. It's therefore important to note each step taken in as much detail as possible so that the analyst reproduces the test case following the same steps. In Expected Results describe your expectation in detail Clearly stating your expectation of the behavior avoids making assumptions, reduces the turnaround time and ensures you will receive a resolution that matches your expectations. In Actual Results describe the behavior you see on your side Clearly stating the behavior on your side together with your expectation of the results supports your case. Do not send a test case in multiple attachments Always capture the logs at the time of testing. If there are any errors, attach them to the HD in log format. Also attach any files used to reproduce the issue.

How to create a supporting test case Stage 1: Attach screenshots of any relevant setup configuration. Examples of screenshots required to support a test case are: Product Definition (important for Fixed Income, Corporate Actions and Position issues), Pricing Params and Workflow (in Excel format), Domain Values, Environment Properties, Trade and SD Filter configuration and Scenario Params. Make sure the screenshots contain the Val Date, Processing Date, Trade Date or Trade Keywords when applicable. Stage 2: Illustrate each Step to Reproduce with screenshots Stage 3: Highlight the relevant fields on the screenshots Stage 4: Clearly show why the Actual Behavior is incorrect and what should be the Expected Behavior. Showing a screenshot where the problem can be seen is often not enough to avoid misinterpretation. A best practice is to circle or highlight, adding text explaining which number is incorrect or which behavior is unexpected. Using different colors is advisable, for example red for incorrect and green for correct. This helps the analyst see and understand the issue clearly. If it can be shown why the behavior is incorrect, for example an incorrect assumption or a formula incorrectly implemented, it could speed up resolution. Stage 5: Demonstrate on the test case why the Expected Behavior detail is correct If a certain number is expected, show how it is derived on the test case. If a certain behavior is expected, clearly explain why the current behavior should be revised (for example: the behavior does not match the documented behavior or is not market practice).

Case Acceptance Check List Criteria Accept? If No, what additional information is required? Yes No Problem Description   A. Summary q B. Product category C. Detailed description D. Business impact or priority E. Recent changes to Calypso product use F. Related product case(s) Environment A. Environment type (production, test) B. Calypso product version C. Database type and version D. Operating system including version E. Recent changes to environment F. Module Version (If case is specific to any module related functionality) G. Cumulative Hotfix Revision No. used in testing (for V13.0 and onwards) Test Case A. Steps to replicate problem in vanilla environment B. Expected results C. Actual results D. Attachments (screen shots, logs, …)

B r e a k i n g t h e b o u n d a r i e s Calypso is a registered trademark of Calypso Technology, Inc., in the United States, European Union, and other jurisdictions. All rights reserved. All products and services referenced herein are either trademarks or registered trademarks of their respective companies. © 2010 Calypso Confidential