oem defect tracking handbookportal.efi.com/.../oem_defect_tracking_handbook.pdf · oem defect...

Electronics For Imaging Confidential

OEM DEFECT TRACKING HANDBOOK This handbook and additional information can be found under: http://portal.efi.com/defect/ OEM should review the documentation available from that web page. This handbook is not designed to explain how to navigate in the database. Its goal is to help define the business rules for using the bug tracking database between EFI QA and OEM QA.

Please email comments / suggestions to improve this handbook to your EFI program manager who will forward them to the correct QA contact person

Last updated on: See revision history

Electronics For Imaging Confidential II

TABLE OF CONTENTS 1. Revision History................................................................................................................................. 1 2. Account Types.................................................................................................................................... 2 3. Generic Information for all accounts .................................................................................................. 3 3.1. Attachments.................................................................................................................................... 3 3.2. Comments....................................................................................................................................... 3 4. Development Defect View ................................................................................................................. 3 4.1. Project Names:................................................................................................................................ 4 4.2. Generalities:.................................................................................................................................... 6 4.3. QA Severities Definitions:.............................................................................................................. 6 4.4. QA Priorities Definitions:............................................................................................................... 7 4.5. OEM Must Fix Definitions:............................................................................................................ 7 4.6. Release Notes: ................................................................................................................................ 7 4.7. QA Bug Status Definitions: ............................................................................................................ 8 4.8. OEM product defect View:........................................................................................................... 10 4.9. Do’s and Don’ts…......................................................................... Error! Bookmark not defined. 4.10. Defect Flow and Ownership During Development................................................................... 11 5. Field Defect View............................................................................................................................. 13 5.1. General Information ..................................................................................................................... 13 5.2. Viewing status information........................................................................................................... 13 5.3. Approved and For EFI buttons ..................................................................................................... 15 5.4. Adding Comments........................................................................................................................ 15 5.5. Adding Attachments ..................................................................................................................... 18 5.6. Exporting Data.............................................................................................................................. 18 5.7. Field Defect Workflows ............................................................................................................... 19 5.8. Field Defect Status Definitions..................................................................................................... 19 5.9. Defect Type Definitions: .............................................................................................................. 22 5.10. Defect Flow and Ownership – Field Defects............................................................................ 23 6. OEM Service Request View............................................................................................................. 24 6.1. General Information ..................................................................................................................... 24 6.2. Viewing status information........................................................................................................... 24 6.3. Field Definitions and Entry Instructions....................................................................................... 25 When logging a new service request, the following fields will be required for entry: ............................. 25 6.4. Adding Comments........................................................................................................................ 27 6.5. Adding Attachments ..................................................................................................................... 27 6.6. Exporting Data.............................................................................................................................. 28 6.7. Service Request Workflows ......................................................................................................... 29 6.8. How to handle feature requests..................................................................................................... 29

Electronics For Imaging Confidential 1

1. Revision History April 9, 2002 First draft completed April 25, 2002 Add section 11 – Field Quality Defects July 25, 2002 Add “For OEM Review” definition in section 7 April 4, 2003 Revised to include “Field Defect” and “Development Defect”

changes July 9th, 2003 Added workflow for Feature request post-shipment July 16th, 2003 Added “For OEM Release” defect status definition September 16, 2003 Added section for OEM Service Requests and updated other

sections January 15th, 2004 Update to the Field Defect Screen, and Status Definition March 9, 2004 Corrected Feature Request workflows and guidelines April 27, 2004 Update Defect Type Definition February 7, 2005 Update many changes to OEM Siebel interface: new views for

improved defect management, new save button, Version / Build fields split, new Owner field.


2. Account Types There are 3 types of accounts:

• “Development Defect” account only • “Field Defect” and “OEM Service Request” account only • Combined “Development Defect”, “Field Defect” and “OEM Service Request” account

The “Development Defect” account is usually given to OEM users that only work with Development products. This provides access to the Development Defects screen. The “Field Defect” and “OEM Service Request” account is usually given to OEM users that only work with Field/Sustaining products. This provides access to the Field Defects and OEM Service Request screens For OEM users who work in both Development and Field/Sustaining products, then the combined account is more appropriate. For the purposes of this handbook, the combined account screenshot has been used. For users that have the combined account, you can simply switch between “Development Defect,” “Field Defect” and “OEM Service Request” screens by clicking on the tabs highlighted by the red box on this picture:


3. Generic Information for all accounts The following information applies to all account types.

3.1. Attachments Please take note when adding attachments to Siebel:

3.1.1. File size limit for one attachment is 100MB 3.1.2. If you have problems uploading files, please contact your technical support

representative.

3.2. Comments 3.2.1. Character limit of 2000

4. Development Defect View This is the view that OEM uses to log defects against currently developing projects.


4.1. Project Names: In the EFI view, defects are reported against the “EFI Project name”. This name must be unique in the database. In the OEM view, defects are reported against the “OEM Project Name”. Because this name also needs to be different from previous project, so we often include the version # in the name.

4.2. Differences Between Siebel Views:

• Defects I own

o Shows only defects assigned to the OEM User logged into Siebel for action. Defects OEM can see in the view should be reviewed ASAP. When a status is changed, the defect is automatically assigned to the EFI QA Lead and the defect will disappear from this view.

o The owner field is visible so the OEM user can re-assign the defect to another OEM user in the same group.

• Defects I Reported

o Shows only defects the OEM user has reported to EFI o The status field is read-only in this view. This is to avoid that OEM

inadvertently change the status of a defect not assigned to him/her.

• Defects my Group Owns o Shows only defects assigned to the OEM’s users’ group for action.

Defects OEM can see in the view should be reviewed ASAP. When a status is changed, the defect is automatically assigned to the EFI QA Lead and the defect will disappear from this view.

o The owner field is visible so the OEM user can re-assign the defect to another OEM user in the same group.

• All Defects

o Shows all defects shared by the OEM and EFI o The status field is read-only in this view. This is to avoid that OEM

inadvertently change the status of a defect not assigned to him/her


• OEM Activities o When a defect is selected in any of the 4 view described above

(Defects I Own, Defects I Reported, Defects My Group Owns, All Defects), selecting this view allows to add comments/activities to the selected defect.

• OEM Activities Detail

o After any of the 4 view described above (Defects I Own, Defects I Reported, Defects My Group Owns, All Defects) is first selected, selecting this view allows to split the screen into 3 sections. The top section shows all defects from the initial view, the middle section shows the defect information for the active defect selected, and the bottom section shows activities for this defect. “OEM Activities” and “OEM Activities Details” are views that respectively allow to see only 1 defect, or multiple defects.

• OEM Attachments o When a defect is selected in any of the 4 view described above

(Defects I Own, Defects I Reported, Defects My Group Owns, All Defects), selecting this view allows to attach a file to the selected defect.

• OEM Groups with Visibility


o When a defect is selected in any of the 4 view described above (Defects I Own, Defects I Reported, Defects My Group Owns, All Defects), selecting this view shows the OEM group(s) that can see the selected defect.

4.3. Generalities: Each time an OEM creates a new defect or changes the status of a defect, it is automatically assigned to the project QA Lead Engineer at EFI. The group field will be automatically updated in Siebel to say “QA”. When EFI assigns defects to the OEMs, the following statuses are used:

For OEM Verify For OEM Review Proposed – No Fix Proposed – Deferred

Proposed - Invalid

4.3.1. “For OEM Verify” and “For OEM Review” defects should always have a comment

“OEM visible” from EFI QA explaining that the defects is ready to be verified or asking for additional information because EFI QA couldn’t reproduce the defect.

4.3.2. “Proposed – No Fix” or “Proposed – Deferred” may not have a comment “OEM

visible” in Siebel for approximately a week. Those defects are initially assigned by engineering to the Engineering Program Manager. It may take a few days for the Engineering Program Manager to be able to provide the OEM a comment explaining why EFI is proposing to make the defect a “Closed – No Fix” or a “Closed – Deferred”. (See status definitions section for more information on this).

To see all defects assigned to the OEMs for review or closure, the “Defects My Group Owns” view should be used.

4.4. QA Severities Definitions: The current list in Siebel is:

QA Leads have ownership of the severity field and should change the severity of any bugs not correctly ranked. EFI QA is responsible to ensure that bug severities are correctly represented in Siebel according to the definitions below: Severity 1: Critical - A reproducible problem where the system has crashed, is non-functional, un-testable, or features are missing.


Severity 2: Severe - A reproducible problem occurring when the system fails to perform core functionality, or features malfunction, or features are somewhat functional but have no workaround. Severity 3: Important – A problem which causes the system to produce incorrect, incomplete,or inconsistent results, or causes system instability. A workaround is available. Severity 4: Minor – A problem that does not affect functionality: cosmetics, feature requests. If a QA Lead Engineer changes the severity of an OEM defects, he or she must make a comment “OEM visible” in activities explaining the change. What to do if the OEM uses different Severities definitions? If the OEM uses different severity definitions, we recommend to the OEM to use the short descriptions field in Siebel to record it. For example if the OEM uses A, B, C ranking using different criteria that won’t align to our definitions, please enter the Short descriptions by [A], [B], or [C]. Then try to also enter the correct severity based on EFI definitions.

4.5. QA Priorities Definitions: The current list is:

EFI QA and OEMs should log all bugs as P0 and the engineering manager / lead is responsible to assign the correct priority. If an OEM logs a bug with a priority other than “0 – Needs review”, the QA Lead Engineer should change it to “0 – Needs review” before assigning it to engineering.

4.6. OEM Must Fix Definitions: In March 2002 EFI added a field in Siebel to the OEM view called OEM Must Fix. The usage of the Must Fix checkbox is to be defined on a per project basis. The general idea is for the OEM to use it to indicate the defects that must be fixed for any project specific milestone date. OEMs own this field. Note that the Siebel system tracks internally when the defects are marked “Must Fix” by the OEM.

4.7. Release Notes: In March 2002 EFI added a field in Siebel to the OEM view called Release Notes. EFI’s documentation group queries this field to find all defects that must be included in the project official final customer release notes. This is essentially for defects “Closed – No Fix” or “Closed – Deferred”. You need to check the flag before closing the defects or you will need to reopen the defect to do so, and then close the defect again.


4.8. QA Bug Status Definitions: Status Owner Definition Open QA or Engineering First defect is being reproduced by

QA for OEM bugs. When reproduced it should be assigned to Engineering.

For Integration Engineering Assign by software engineer to Integration Engineer or Engineering Lead to notify him/her that a label was submitted to be included in the next build. Once the build or solution is completed and released to QA the status should be changed to For Verify and the bug should be assigned to a QA tester for verification. The build version should always be updated in Siebel.

For Verify QA Fix submitted by Engineering to QA. The status should only be “For Verify” only once the build or solution has been submitted to QA.

For OEM Verify OEM

Fix submitted by QA to OEM for verification after internal verification, once a build or solution is released to the OEM.

For OEM Review OEM

A defect that is missing steps to reproduce, necessary test files, or that EFI QA cannot reproduce. Also used for defects that EFI believes to be a user error. Also used for defects that EFI believe to be copier/OEM defects. EFI QA and engineering must add activities to the defect explaining to the OEM what information is needed from them or why EFI thinks it is an invalid defect or copier/OEM defect.

For OEM Release QA A defect that has been verified by EFI QA already and will be made “For OEM Verify” once a build with the fix is released to the OEM.


Proposed Deferred Program Manager A defect that EFI recognizes as valid, but engineering proposes to defer the fix to a future project release and assign the defect to the PM for review. PM will review, add comments and assign it to the OEM for approval. The primary reason for this status is that fixing the bug is risky and is likely to impact the schedule. The PM will negotiate “No Fix” proposal with OEM and provide activities in Siebel.

Proposed-Invalid Engineering/QA/EPM Engineering investigation shows that this defect is invalid. This status is set, so that EFI and OEM understand and agree on the issue. After agreement, status changes to Closed - Invalid

Proposed No Fix Program Manager A defect that EFI recognizes as valid, but engineering has no plan to fix the defect in a future project release or engineering has concluded that the defect isn’t an EFI defect. The PM will negotiate the “No Fix” proposal with OEM and provide activities in Siebel. Assigned to PM by Engineering.

Deferred NA Fix deferred to: (TBD). Assigned to PM by QA

Closed – Patch NA Sustaining only. Patch approved, released to Tech Support

Closed – Invalid NA Not a valid defect, i.e. duplicate, user error, etc.

Closed – Workaround NA Sustaining only. Acceptable work around for field reported defect, i.e. configuration change, etc.

Closed – No Fix GM/VP, EPM, or OEM Business decision made by GM/VP not to fix Defect or provide patch. (or OEM acceptance of Proposed No Fix). ). Only OEM, VP/GM and EPM can use the “Closed – No Fix” field in Siebel.

Closed – Fixed NA Changed from “For Verify” or “For OEM Verify” after a fix is verified successfully in a build.

Closed – Duplicate NA Use to close 1 of 2 identical defects. If one is reported internally and one is reported by the OEM, the internal defect should be “Closed – Duplicate”.

Closed – Not Reproducible NA Use to close a defect that QA can no longer reproduce although no label/information was provided by engineering to identify the fix.


Closed – Spec. Chg. NA Use to close a defect when the software has not changed but the specification has been updated or clarified, and the issue explained in the bug is now acceptable per specification.

Closed NA This status should not be used on Current Projects. Effective Aug 2001.

4.9. “SAVE” Button: In January 2005 a “save” button was added to Siebel.

Parameters are saved when user change from one Siebel screen to another. However if changes are made and the Siebel user closes the browser without changing any screen first, changes on the last defect screen could be lost. Clicking "Save" before closing Siebel guaranties nothing will be lost.

4.10. Version and Build Fields:

• *Build – Found

o This field is required when entering a new product defect. Use it to record or view which system software build the defect applies to.

• Version – Found o Use this field to record or view the user software (driver/utility) version that the

defect applies to. This is an optional field. • Build – Fixed

o Use this field to record or view which system software build will contain the fix for the defect

• Version – Fixed o Use this field to record or view which user software (driver/utility) version will

contain the fix for the defect

4.11. Queries: Whatever is seen in the center on the screen in Siebel is controlled by 3 selections (see screenshot):

• Choice between: “Development Defect” or “Field Defect” or “OEM Service Request” • Choice between: Defects I Own, Defects I Reported, Defects My Group Owns, All

Defects • Choice of query. Default query ”All Active Defects”


You can create and save your own queries from the Tool bar Query menu. The default query “Active Defects” is defined as follow: Status: NOT ( LIKE Close*) AND NOT ( LIKE Def*)

4.12. Defect Flow and Ownership during Development The chart below is provided to help you understand the internal flow of statuses and ownership of defects in Siebel. Ownership is represented by the Group field in the OEM views.


Field Defect View This is the view that OEM uses to see Field Defects logged through Technical Support.

4.13. General Information Field defects are issues reported from the OEM through EFI technical support. EFI Technical Support will generate a Service Request. After verification of the OEM claim, EFI TS will convert the Service Request to a Siebel Defect, if it requires further investigation by EFI Engineering. Each OEM Field Defect has a Service request associated with it. The “Field Defect” view is intended for our OEMs to:

• View real time status information for field defects (does not include pending Service requests- see OEM Service Request view in Section 6 of this document.)

• Add comments • Add attachments • Export information for data management

4.14. Viewing status information


To view Field Defects, simply select from the following two choices: • “My Field Defects” tab • My Group’s Field Defects tab

“My Field Defects” Tab will show defects assigned to your current login “My Group’s Field Defects” Tab will show all the defects reported by your group All the fields in the “Field Defect” view are similar to the “Development Defect” view. The new additions are:

• SR ID and SR Created Fields • Group • OEM Project Name • OEM Delivery Date

4.14.1. “SR ID”, “SR Created” and “Group” Fields

• “SR ID”: is the service request associated with this defect • “SR Created”: is the creation date of the service request • “Group”: is the current group that is investigating the Siebel ID. (For example: QA, Eng)

4.14.2. “OEM Project”

This is the OEM Project name provided during the “Development Defect” cycle.

4.14.3. “OEM Delivery Date”


This is the estimated delivery date of a solution to the OEM. If there are any changes to the delivery schedule, EFI will promptly update this field.

4.15. Approved and For EFI buttons

"FOR EFI" button: When a defect is assigned to the OEM as "For OEM Review" or “Proposed – XXX), the OEM can now return the defect back to QA, by pressing this new button. "APPROVED" button: When a defect is assigned to the OEM as "For OEM Verify" or “Proposed – XXX), the OEM can now return the defect back to QA for final release. Once they click this button, the Status will change to "For OEM Release" and assigned to QA. The functionality of these two buttons are enabled ONLY when the status is: "For OEM Verify" ,"For OEM Review" or “Proposed – XXX”

4.16. Adding Comments It is important to emphasize that the channel of communication for the OEM is EFI Technical Support. All field defects related communication is to be done through technical support, using Siebel as the communication tool. Technical Support will promptly respond to your comments with an appropriate update. It is EFI’s commitment to maintain data accuracy in Siebel. If by some reason we are unable to deliver on the “OEM Delivery Date”, we will promptly update you. To enter an activity, follow these steps:

• Select the defect you want to add a comment on, and select the “OEM Field Activities” tab


• Place your mouse cursor over the “OEM Field Activity” Panel, and click on it to enable:

• Right click and select new record

• A new activity entry is created. Proceed to the “Comment” Column and enter your data. Please note that while you do this, the “Activity Type” Column is blank by default. Once you fill the data and save, the entry is filled with “Sustaining OEM Communication”.

After you entered the activity, the right people will be notified, and they will promptly respond.


4.17. Adding Attachments To add attachments, you follow the same procedures as the “Development Defect” View. We request that when you attach a file, you also write a comment indicating the purpose of the file, and how this file will help the resolution of the field defect. Here is a screenshot of how the attachment view looks like:

4.18. Exporting Data Siebel offers the capability of exporting the data you are seeing on the screen into three file formats: HTML, Tab delimited text file and CSV (used in excel). Here is a screenshot of the export data feature:


4.19. Field Defect Workflows The following are workflows that will allow us to efficiently communicate through Siebel.

4.19.1. If you need to obtain a status update on a field defect that is overdue and has no status update from EFI, please add a comment, and the right teams will be notified to address your concerns

4.19.2. If you need to add more information that will help the resolution of the defect, please add any attachments or data into Siebel

4.19.3. When a status is set to status “For OEM Verify”, and the OEM has finished the solution verification, please enter an comment in Siebel, and we will promptly address the defect.

4.19.4. When a status is set to status “For OEM Review”, and the OEM has completed the missing information or reviewed EFI’s request, please enter an comment in Siebel, and we will promptly address the defect.

4.20. Field Defect Status Definitions Status Owner Definition Open QA or Engineering Field Support: defect is being

analyzed and possible solutions/workarounds are being studied by Engineering and Sustaining QA


For Integration Engineering Assign by software engineer to Integration Engineer or Engineering Lead to notify him/her that a fix is ready for integration. Once the build or solution is completed and released to QA the status should be changed to For Verify and the bug should be assigned to a QA tester for verification.

For Verify Sustaining QA Engineer Fix submitted by Engineering to QA. The status should only be “For Verify” only once the solution has been submitted to QA.

For OEM Verify Field Support: EFI TS Engineer who logged the defect owns the defect number

Fix submitted by QA to OEM for verification after internal verification, once a build or solution is released to the OEM.

For OEM Review Field Support: EFI TS Engineer who logged the defect owns the defect number.

A defect that is missing steps to reproduce, necessary test files, or that EFI QA cannot reproduce. Also used for defects that EFI believes to be a user error. Also used for defects that EFI believe to be copier/OEM defects. This information will be communicated, by EFI TS to the OEM, via Siebel. Once an agreement between OEM and EFI has been reached, defect will be changed to status “closed invalid” or “closed not reproducible”

Proposed Deferred Program Manager A defect that EFI recognizes as valid, but engineering proposes to defer the fix to a future project release and assign the defect to the PM for review. PM will review, add comments and assign it to the OEM for approval. The primary reason for this status is that fixing the bug is risky and is likely to impact the schedule. The PM will negotiate “No Fix” proposal with OEM and provide activities in Siebel. Defect remains assigned to EPM until agreement with OEM has been reached. Once agreement is reached, Status changes to deferred.

Proposed - Invalid Engineering/QA/EPM Engineering investigation shows that this defect is invalid. This status is set, so that EFI and OEM understand and agree on the issue. After agreement, status changes to Closed - Invalid


Proposed No Fix Program Manager A defect that EFI recognizes as valid, but engineering has no plan to fix the defect in a future project release or engineering has concluded that the defect isn’t an EFI defect. The PM will negotiate the “No Fix” proposal with OEM and provide activities in Siebel. Assigned to PM by Engineering.

Deferred NA Definition is currently being evaluated for accuracy and clarity. Definition was: Fix deferred to: (TBD). Assigned to PM by QA.

Closed – Patch NA Patch approved, released to Tech Support

Closed – Invalid NA Not a valid defect, i.e. duplicate, user error, etc.

Closed – Workaround NA Acceptable work around for field reported defect, i.e. configuration change, etc.

Closed – No Fix GM/VP, EPM, or OEM Business decision made by GM/VP not to fix Defect or provide patch. (or OEM acceptance of Proposed No Fix). ). Only OEM, VP/GM and EPM can use the “Closed – No Fix” field in Siebel.

Closed - Fixed NA Solution provided to OEM via a non-patch method. For example: PPD, driver release, new utility, etc…

Closed – Duplicate NA Use to close 1 of 2 identical defects. If one is reported internally and one is reported by the OEM, the internal defect should be “Closed – Duplicate”.

Closed – Not Reproducible NA Sustaining QA, Engineering and Technical Support can not reproduce the defect.


4.21. Defect Type Definitions: In the Post-Release phase of our products, EFI releases different type of patches:

• There are patches that are released as conditional approval patches to development products during final stages.

• There are patches that solve defects directly reported from the field. • Other patches solve problems reported from Product Development and

Sustaining QA. • Or we may release patches that enhance the feature set (in which case, it’s

not a defect resolution, but a feature enhancement). Definitions: Defect: these are defects created during product development. (Either by EFI or OEM) Feature Request: these are feature requests created during product development or post-shipment. Defect-Post Rel. (Defect-Post Release): these defects originate from Product QA - OEM during product development. This happens during the final stage of the product when OEM does not want to take new fixes in the Golden Master software. Therefore, EFI-OEM agrees to release the fixes in the form of patches through the Customer Support-Manufacturing channel. (also known as conditional patches). Defect-Field: these are field defects reported from the OEM. They come to us as a consequence of a Service Request being converted into defect. Defect-Prod. Updt (Defect-Product Update): these are defects that EFI found after the product launched, and is proactively releasing a patch to address the issue. (With OEM Approval)


4.22. Defect Flow and Ownership – Field Defects

Sustaining QA

EFI regional Tech Support office

OEM EFI salesEnd user

Engineering

Program ManagementPM decides no patch, or postpone to next software release

Sustaining QA changes bug status to Proposed No Fix

Sales

PM decides to make patch

Sustaining QA works withEngineering to ensure patch release following the patch release process

Patch distributionto originator for approval

Sustaining QA doesofficial patch release to Siebel database

Sustaining QA checksEngineering documentationof patch and transfers to QA lead for new products

The preferred path

Alternative path, slower

Issue is identified as major feature request

Product Marketing / Product Planning

ServiceRequest

Defect

Siebel

All Field Defects are reported through EFI Technical Support.


5. OEM Service Request View This is the view that OEM uses to log service requests for review by Technical Support.

5.1. General Information Service Requests are issues reported from the OEM to EFI Technical support. Reproducible, verified issues are converted to Field Defects. The “OEM Service Request” view is intended for our OEMs to:

• Log new Service Requests • View real time status information for pending Service Requests • Add comments • Add attachments • Export information for data management

5.2. Viewing status information To view Service Requests, simply select from the following two choices:

• “All Service Requests” tab • “My Service Requests” tab


“All Service Requests” Tab will show all service requests for your OEM “My Service Requests” Tab will show all the service requests that the person currently logged in has reported

5.3. Field Definitions and Entry Instructions

When logging a new service request, the following fields will be required for entry: • SR #

The EFI service request number in Siebel will be automatically generated when you enter a new Service Request.

• OEM ID Enter your internal case id or log number for the service request

• Contact Information: All will default once Last name is selected.

o Last Name Click on the drop down arrow to view the contact selection box or type in the last name of the contact for the new service request. In the contact selection box, all contacts for your OEM will display.

o First Name This field will default when you select the contact (Last name) for the service request

o Account This field will default when you select the contact (Last name) for the service request

o Email This field displays the customer’s contact email address and will default when you select the contact (Last name) for the service request

o Phone

This field displays the customer’s contact phone number and will default when you select the contact (Last name) for the service request

Note: If any of the above contact information requires updating in EFI’s database, please contact your Technical Support Lead.

• Status This field is read only. It will default to the value “Review for Defect.”

• Date Opened This field is read only. It displays the date of entry for the service request.


• Date Closed This field is read only. It displays the date that EFI has closed the service request.

• Owner This field is read only. It displays the EFI Technical Support Lead responsible for the Service Request.

• Attachment (checkbox) When selected, this checkbox indicates that the service request has an attachment. It defaults when a new attachment is added.

• Short Description

Use this field to provide a concise summary of the issue. Maximum 100 characters.

• SR Subject The following subjects are available for selection:

• Network Type Use this drop down selection field to indicate the network type, if applicable. If not applicable, please select “N/A.”

• Client OS Use this drop down selection field to indicate the client operating system, if applicable. If not applicable, please select “N/A.”

• OEM This field is read only and defaults to your OEM.

• Product Use this drop down selection field to choose the product experiencing the issue. If you are not sure which product to select or cannot find the appropriate option, contact your Technical Support Lead.

• Version This field defaults from the product selection.

• OEM Print Device Use this drop down selection field to choose the printer or copier model experiencing the issue. If you are not sure which OEM Print Device to select or cannot find the appropriate option, contact your Technical Support Lead.

• Serial # This field is optional. Enter as appropriate.


• Severity: This field is optional. Please use the following guidelines to select severity of the service request. Severity 1: Critical - A reproducible problem where the system has crashed, is non-functional, un-testable, or features are missing. Severity 2: Severe - A reproducible problem occurring when the system fails to perform core functionality, or features malfunction, or features are somewhat functional but have no workaround. Severity 3: Important – A problem which causes the system to produce incorrect, incomplete, or inconsistent results, or causes system instability. A workaround is available. Severity 4: Minor – A problem that does not affect functionality: cosmetics, feature requests.

• Priority

This field is optional. Select as applicable to your defect; 0 is “needs review” and 1 is highest priority, 3 is lowest.

• Steps to Reproduce

Use this field to provide a detailed, step by step explanation of how to reproduce the issue. Maximum 2000 characters.

5.4. Adding Comments EFI’s Siebel system provides the option to enter comments related to a Service Request. Entry of new comments will trigger an email notification to the appropriate EFI Technical Support Lead. Technical Support will promptly respond to your comments with an appropriate update. To enter a comment, follow these steps:

• Select the service request you want to add a comment on, and select the “Activities” tab

• Place your mouse cursor over the “Activities” Panel, and right click to select New Record:

• A new activity entry is created with the default Activity Type of SR OEM Communication. Please do not change the Activity type! Proceed to the “Comments” Column and enter your data.

After you entered the activity, the right people will be notified, and they will promptly respond.

5.5. Adding Attachments EFI’s Siebel system provides the option to enter attachments related to a Service Request. These might include customer files necessary for EFI to reproduce the issue, screenshots or other pertinent data. Entry of new attachments will trigger an email notification to the EFI


Technical Support Lead. Technical Support will promptly review the attachment and respond with an appropriate update.

5.5.1. Note: File size limit for one attachment is 100MB To enter an attachment, follow these steps:

• Select the service request you want to add an attachment to, and select the “Attachments” tab

• Place your mouse cursor over the “Attachments” Panel, and right click to select New

Record.

• A new attachment line item is created and your will be prompted to attach a file. After you entered the attachment, the right people will be notified, and they will promptly respond.

5.6. Exporting Data Siebel offers the capability of exporting the data you are seeing on the screen into three file formats: HTML, Tab delimited text file and CSV (used in excel). Here is a screenshot of the export data feature:


5.7. Service Request Workflows The following are workflows that will allow us to efficiently communicate through Siebel.

5.7.1. When a new service request is entered, the status will be set to Review for Defect and a notice will be sent via email to the appropriate EFI Technical Support Lead.

5.7.2. If you need to obtain a status update on a service request, please contact EFI directly or add a comment to the service request, and the right teams will be notified to address your concerns

5.7.3. If you need to add more information that will help the reproduction of the service request, please add any attachments or data into Siebel

5.8. How to handle feature requests Use the Siebel OEM Service Request screen to enter new feature requests. To indicate a Feature Request, select the SR Subject “Feature Request.” EFI Technical Support will review the service request and, after gathering all supporting documentation, convert it to a Siebel Defect, with defect type set to “Feature Request”. Feature requests are not bound by a resolution time, as specified in the agreements. Please provide relevant supporting data for the request. Please contact Program Management for status on your request. Feature requests that come outside of the OEM-Siebel interface will not be logged as a defect type “feature request”, but it will be transferred to the Feature request list, by converting the SR to Feature request.

oem defect tracking handbookportal.efi.com/.../oem_defect_tracking_handbook.pdf · oem defect...

Documents