Defect Ticket Checklist This is a more detailed version of the Trouble Shooting page.

IMPORTANT NOTES:

1. A good defect ticket can take hours to create. If you can not spend the time to create a proper defect ticket then you should call Paul or Garth and walk them through the issue you're having.
2. Defects are for core code only. If you can't replicate the issue in the core code but it exists in the adopter code then this is an adopter support issue/task.
3. Defect tickets need to include very detailed information so that anyone can replicate the problem – from the developer to the tester that has to validate that the issue has been fixed.
4. Defect tickets are important. They make sure that problems are addressed and that the fixes have been independently tested and verified.
5. The application will not be released until all of the associated version's defect tickets are tested and closed (or reassigned).
6. When creating a ticket the main areas to focus on are "Describe the Application" and "Describe the Problem".
7. The issue should be included in the test set. The test set should at a minimum include the URL and the steps.

---

ITEMS TO CONSIDER (defect/bug tickets):

1. Try and provide a concise summary of the problem that is somewhat specific (this is subjective) here's a few examples: :
   • Problem with the view application (FAIL).
   • View application fails to startup on Websphere 10.3 (PASS).
   • Query result page does not work (FAIL).
   • Query result page's data table does not display cross3 values (PASS).
2. Describe the application (which application? which version?):
   1. Is the problem on the public production server using released code? If so then there should be a release snapshot in the adopters repository area that includes the adopter's code and the core code used. Include this base adopter released snapshot version repository URL.
   2. If the problem is with non released development code then the adopter needs to first determine if it is their adopter specific code or core code. The adopter should export the core code only and test. If the problem is only seen running then adopter version and the core code doesn't have the issue then it's an adopter support issue – it's not a defect ticket - defect tickets are only for core code. If it is an issue with the core, trunk development code then the adopter should report the export date of the core code used.
3. Describe the application environment:
   • Client Issues (app works and data is correct but page doesn't format correctly or interaction is not correct):
     1. If it is a problem with the screen displaying/not displaying, formatting something correctly then it is likely a CSS or XSLT/HTML issue. Need to include the browser(s) and version(s) tested. Example for a site navigation menu overflow problem (assumes already described): Displays correctly using IE 10, Chrome 38.0. Has problem with IE 6&7.
     2. If it is an interactive issue (interactive map, chart, grid, wiki formatting, popup dialog, or even table column sorting etc.) then it might be a javscript issue. Test with different browsers and versions if possible and include those findings. In addition if you can attached a copy or screenshot of the browser's console log that shows javascript errors that is very helpful.
   • Other - Server Issues (app doesn't start, wrong data displaying, wrong request etc.):
     1. Which version of Tomcat (or specify the application server and its version)?
     2. Does the application server start without IBIS apps installed? Is this a new app and/or application server install? Do other IBIS apps run? Have you successfully ran other versions of the application with the same app server enviro?
     3. Where is the code running? Local PC or server?
4. Describe the problem:
   1. Include the URL of the page that has the problem.
   2. Include every step that is needed to produce the problem (this is the most critical information to provide and MUST always be included - never assume - always describe the steps so that any non IBIS person can reproduce the issue).
   3. This could include ALL web pages hit that are associated with the problem.
   4. List all selections that are made on said pages. Include screen shots if needed.
   5. If it is a query module save the query definition and provide the URL etc.
   6. In general if it is a query problem what URL is created for IBIS-Q? Does that URL return the correct data from IBIS-Q? Is the data correct in the query module's XML?
   7. Describe expected behavior - what should have happened/what should be normal behavior.
   8. Describe what did happen.
   9. Include any screen shots of the problem etc.
   10. If you received the IBIS error page, click on the “bug” icon and include the first 5 lines of the exception stack trace or at least the main error message title.
   11. If possible include any console log error messages (see Paul Leo for more information about this).
   12. Include any other information that is needed to replicate the problem – who are you logged in as, what privs do you have, etc.

---

BOTTOM LINE: The above items are a basic checklist of items that you *COULD* include. Use discretion - only include things that add value. Remember a defect ticket needs to include as much information as possible so that it can be adequately understood by all and replicated/verified by a tester.

See ​Trac Ticket Usage DOC for more info.