Enhancement of Error Handling during API call

[MaximilianHauer]

Description

Feature Team

Committer

@evegufy / @Phil91 / @oyo / @ntruchsess

Contributor

@oyo / @ntruchsess

Explain it in two sentences

Improve the Error Messages to support multiple languages, standardize the error handling, and standardize the presentation of error messages in the frontend.

What's the benefit ?

Misbehavior is better understood by the user and enables them to more easily solve their problems independently, resulting in a better user experience and reduced load on customer support.

What are the Risks/Dependencies ?

• No dependencies to other systems

Detailed explanation

Current Implementation

The current implementation of Error Handling provides a suboptimal user experience. Different methods are used to display errors, and in most cases, the reason for the error is not provided to the user. This lack of clarity hinders users from understanding the problem and resolving it independently.

This situation could lead to users contacting support more often, which creates unnecessary effort for the operations department.

Proposed Improvements

The user should receive a clear and understandable error message that explains the cause of the problem. This will enable the user to solve the issue themselves or at least provide better information to the support team to act on a solution.

By implementing these improvements, we can enhance the user experience by providing clear and understandable error messages, which will reduce the need for user support and empower users to solve issues independently.

To ensure multi-language support, the error messages should be displayed in the user's selected language.

User Stories

• sig#882 - Implement a Generic Error Handling Method in the Frontend portal-frontend#1166
• sig#882 - Refine Backend Error Messages portal-backend#1044
• sig#882 - Refine Backend Error Messages portal-backend#1045
• sig#882 - Identify Error Message Locations in the Frontend portal-frontend#1167
• sig#882 - Remove deprecated code portal-backend#1046

Acceptance Criteria

Note: We will provide the Acceptance Criteria on User Story Level

Testcases

Test Case 1: Display of Error Message in User's Selected Language
Description: Verify that the error message is displayed in the user's selected language when an error occurs.
Steps:

1. Log in to the application with valid credentials.
2. Set the preferred language to a non-default language (e.g., Spanish).
3. Perform an action that is known to trigger an error (e.g., input invalid data in a form).
4. Submit the form or complete the action to trigger the error handling mechanism.

Expected Results:
The error message should be displayed in the selected non-default language (Spanish in this case).
The error message should clearly state the reason for the error.
The user should be able to understand the error message without ambiguity.

Test Case 2: Clarity of Error Message for Form Validation
Description: Ensure that the error message for form validation is clear and provides the reason for the error.
Steps:

1. Log in to the application with valid credentials.
2. Navigate to a form within the application.
3. Fill out the form with invalid data (e.g., an incorrect email format).
4. Attempt to submit the form.

Expected Results:
An error message should be displayed near the field with the invalid data.
The error message should specify the exact reason why the data is invalid (e.g., "The email address is not in a valid format").
The user should be able to correct the error based on the information provided in the error message.

Test Case 3: Consistency of Error Display Methods
Description: Check the consistency of error display methods across different parts of the application.

Steps:

1. Log in to the application with valid credentials.
2. Trigger different types of errors by performing various actions (e.g., network error, form validation error, page not found).
3. Note the method of error display for each type of error (e.g., popup, inline message, dedicated error page).

Expected Results:
The method of displaying errors should be consistent across the application.
The user should not experience different methods of error display for similar types of errors.

Test Case 4: Error Message Accessibility
Description: Ensure that error messages are accessible to users with disabilities, such as those using screen readers.
Steps:

1. Log in to the application with valid credentials using a screen reader.
2. Perform actions that trigger errors.
3. Listen to how the screen reader announces the errors.

Expected Results:
The screen reader should clearly announce the error messages.
Users with visual impairments should be able to understand the error and its cause through the screen reader's announcement.