ScorpionSting Absent Member.
Absent Member.
3926 views

SR's & Bugs

So, I just need to understand what the policy is supposed to be.....

I've had bug's raised as a result of a SR, then the SR gets closed and the bug is "employees only"....so I've lost complete view of when the bug will be fixed with the SR providing no workaround.

This seems to be completely counter intuitive.

Visit my Website for links to Cool Solution articles.
0 Likes
7 Replies
ScorpionSting Absent Member.
Absent Member.

Re: SR's & Bugs

Hmmm....got call as result of Survey against one of these....both have been reopened now

Visit my Website for links to Cool Solution articles.
0 Likes
tbaki Absent Member.
Absent Member.

Re: SR's & Bugs

Hello,

Thank you for asking the question.
Normally when a defect needs longer to resolve, more than 1 month, the engineer may chose to temporarily close the SR.
Temporarily means both customer and engineer would still get automated email notifications every time the defect is updated.

Once the fix is officially available, the engineer would re-activate the SR, and follow up with the customer to make sure it does what it is supposed to do.
If the fix does not meet the needed requirements, Engineering needs to follow up the defect.

Even if the SR is closed, activities would still happen.
Instead of the SR being used as a place holder, the defect is used instead.
Even though there is no visibility, the SR is still listed as Closed, Awaiting Engineering, or Awaiting Public Patch, in NCC.
It becomes the engineer's responsibility to close the loop.

I hope the above answers your question.

Regards
Tarik
ScorpionSting Absent Member.
Absent Member.

Re: SR's & Bugs

Theory sounds okay, but I think reality is very different. As a customer, I need a direct contact point to check in when the resolution to the defect is going to be released and this is not possible if the SR is closed off and the bug is inaccessible.

Even when I have had bugs tied to an SR, the only piece of information I ever received is the notification of the release several days after the patch is actually out (likely when the bug is marked resolved). This alone is insufficient.

Visit my Website for links to Cool Solution articles.
0 Likes
tbaki Absent Member.
Absent Member.

Re: SR's & Bugs

Thank you for highlighting ways to improve our customer interactions for defect related issues.
If the theory does not work as expected, we need to review it.

Defect updates should not really only be once after final release of a fix.
It should be with every status change meant for external communication.

If I understand you correctly, you are using the SR as a sounding board to ask for regular defect updates.
This is still a manual process needing the engineer to regularly update customers, and this could also be frustrating.

If you are interested in a time frame for a defect fix, then I would recommend that defects need to be properly prioritized. This way developers fix it in an acceptable time frame.
Of course both business and operational impact are needed and communicated back to Engineering.

If, on the other hand, a defect is not considered a high priority by customers, then it will likely take more than a month to fix.
This is when automated defect updates are generally accepted by customers.

An SR remaining open for over 3, 6, and 12 months due to defects, hardly adds values, and does not reflect good practice..

If you were automatically updated via defect, every-time it changes status, would that be acceptable?

I must reiterate that the SR is only "temporarily" closed until a fix is released, or until such a time customers ask for it to be reactivated.
0 Likes
ScorpionSting Absent Member.
Absent Member.

Re: SR's & Bugs

When a bug is marked for "Micro Focus Employees Only", no external communication would occur. And as this is 100% the case when a bug is logged via a SR, then no bug update affects the SR. Then with bugs I log (making them external) and tie them to a SR, almost 100% of the engineering updates are private so, again, the process falls apart.

I have at least 2 SR's and their relative bugs that are completely stopping us from moving any version of IDM 4.6.x beyond the DEV environment. These are critical as IDM 4.5.x current ends support February 2018 (which we can't meet as it is with December and January always unavailable for changes to our environments). I know one of the bugs is tied to bigger issues around the ECMA implementation in the 4.6 release, so is high priority with engineering.

I have SR's that are almost 2 years old, simply because of the lack of any traction by engineering. Without the SR remaining open, I wouldn't have front line available to always be chasing engineering for a response....and now making them 100% under the Product Manager radar.

All in all, the whole engineering process needs a complete overhaul if any SR/Bug process is going to work correctly....until that happens, making promises about "system notification functionality" would be pointless.

Visit my Website for links to Cool Solution articles.
0 Likes
tbaki Absent Member.
Absent Member.

Re: SR's & Bugs

If you say the defects are high priority then the SR's should not be closed in the first place. This way the engineer provides regular updates until closure.

Each product portfolio has its own bugzilla guidelines. Maybe it is the case for IDM that every defect logged is marked employee only, but this is not the case for other products. I will investigate and let you know. Just to clarify that we are not talking about engineering updates being visible and shareable via email.
I am referring to the defect status change.

I was not making promises, I was seeking your feedback. Anyway, it has come across loud and clear.
0 Likes
Knowledge Partner
Knowledge Partner

Re: SR's & Bugs

ScorpionSting wrote:

>
> All in all, the whole engineering process needs a complete overhaul if
> any SR/Bug process is going to work correctly


I concur completely!

I have raised similar issues in the past as have other Knowledge
Partners. We would be happy to provide our input if it would help
resolve these issues.

It's unfortunate that different products have different rules and
processes. When dealing with vendors, Customers expect issues to be
resolved in a consistent manner independent of the specific product!


--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
_____
Kevin Boyle - Knowledge Partner - Calgary, Alberta, Canada
Who are the Knowledge Partners?
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.