Are you logging defects for all robot failures?

Help
1

There are business and system exceptions that can happen daily during hypercare… Some business exceptions required quick modifications to deploy.

Are you logging all exception defects that require changes to projects? Some are doing this in order to track effort based on all defects logged/resolved… . Even if the fix is 5mins and retest is just as quick.

3 Likes
2

Yes ,

As soon as the hypercare start - I maintain an Excel where I keep track of daily run. For the failures I categorize them among - environment issues, config issues , input issues , orchestrator issues.

I then get the percentage of success vs failures.

For failures - Whatever changes are done is also recorded , this endures that we do not have the same issue again.

Issues resolved by updating config stabilizes the config for production.
Issue resolved in environment fix the issue for coming future.
And do on.

Hope it make sense !

Happy to learn a better way

–
Mukesh

1 Like
3

Hi @lestermendoza,
actually it’s up to your job level , I’m sorry actually we didnt know your job level
But as a best practices I think its better to have all logging at least for implementation level
Some times will help you to explain the issues to others
(I hope you are talking about keeping issue tracker )

4

@mukeshkala the spreadsheet seems like a good option within a small organization or development team. However, we are seeing that larger organizations want better visibility to the failures and ultimate fixes that are being implemented.

We usually suggest that end users initially review the Kibana dashboards and then see if a defect has been logged in Jira. Some dev teams also categorize the failures and some teams face the challenge of what should be fixed. We advise that any failure that occurs more than twice should be logged as a defect. The initial occurrence is usually observed and analyzed to determine if critical or not.

There is no bullet proof answer, but I wanted to see what others are experiencing.

1 Like
5

@Maneesha_de_silva I would hope that developers who worked on the process are always made aware of any robot failures to give them awareness regardless of level. The actual logging may not occur by the developer, but awareness can start with the logging in an issue tracker and subsequent downtstream/upstream notification :+1:t5:

6

@lestermendoza yes your exactly right :slightly_smiling_face::ok_hand:

7

I work in the highly regulated insurance industry, so we need to have full documentation for anything that’s potentially going to touch any of our systems. We have a testing phase that somewhat resembles the hypercase model, but we do so in a test environment and only allow things to enter into production after they have been signed off as having worked correctly for a reasonable amount of time, transactions, and cases. If anything happens like what you are talking about, where there’s an issue with a process that is in production, from what I have noticed, it is usually a fault with the end user’s testing of the process and not the process itself. Usually these are then considered on a case by case basis whether or not it’s worth going back and fixing the issue as that is technically a completed project and additional time and resources would need to be allocated in order to create a hotfix.

8

Having hyper-care performed in a “Pre-Prod” environment is definitely a good approach for projects that can do it. This allows for easier implementation of fixes without going through the more stringent issue logging requirements of a PROD environment.

Unfortunately, it is sometimes a challenge just to get a UAT environment :slight_smile:

You are right about assessing the production issues and most logging the issue to be implemented in a future maintenance release.