© 2013 calypso confidential calypso help desk case submittal best practice 1 © 2010 calypso...

© 2013 Calypso Confidential

Calypso Help Desk Case Submittal Best Practice

1 © 2010 Calypso Confidential

Product Support October 2013

© 2013 Calypso Confidential© 2013 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

2



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.

3



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”

4



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.

55



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.

6



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.

77


How to report an issue

Describe the issue as clearly and simply as possibleThe 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.

8

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 detailClearly 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 sideClearly stating the behavior on your side together with your expectation of the results supports your case.

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.

Do not send a test case in multiple attachments

Example


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.

9

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 correctIf 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).

Stage 1

Stage 2 and 3

Stage 4 and 5 - Final


Case Acceptance Check List

10

CriteriaAccept? If No, what additional information is

required?Yes No

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

© 2013 Calypso Confidential

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 Confidential11

© 2013 calypso confidential calypso help desk case submittal best practice 1 © 2010 calypso...

Documents