Retest based on received error message

Last modified by Danniar Firdausy on 2024/09/18 13:18

In our previous microlearning, we covered how to determine the cause of an error message using eMagiz. Now, we’re going to focus on the next crucial step: validating your fix through retesting. This microlearning will guide you to do this by using the flow testing functionality to ensure that the changes you made indeed resolve the error. We will cover how to test your flows effectively and validate that your solution works as intended.

Should you have any questions, please contact academy@emagiz.com.

1. Prerequisites

  • Basic knowledge of the eMagiz platform
  • Basic knowledge of cloud management

2. Key concepts

This microlearning centers around retesting based on received error message

  • With retesting, we mean: Testing after a change has occurred whether the change in question resolves the given error.
  • Retesting is a way to validate your assumptions
  • If you have multiple scenarios that could happen within the context of your flow ensure to test them all for regression
  • By retesting you deliver better quality to the client

3. Retest based on received error message

In our previous microlearning, we learned about determining the cause of an error message. In that microlearning, we learned that with the help given by eMagiz you as a user can determine the cause of an error message. However to validate your assumption you need to test your change before announcing to the world the error has been fixed. In this microlearning, we will focus on the part of retesting your flow(s) to validate that your change did indeed solve the error. We will use the flow testing functionality to perform these tests.

In our previous microlearning, we fixed what we thought caused the issue. Now we will retest the flow(s) linked to the error to see if we were right. To do so navigate to the Create phase and open the flow in which you made a change. Open the test canvas within the flow designer. Here we adjust the expected message to state that we expect whatever value is in Onderdeel to end up in Component. After we have made the adjustment we run the flow test again to see whether or not our change ensures that the Component attribute is filled in. For detailed information on flow testing please check out the Crash Course Platform. As a result, we expect to see a blue background.

intermediate-active-monitoring-retest-based-on-received-error-message--result-retest.png

Now that we now we have a successful test we should use the expected message on the CDM level as input for a second test on the offramp level to see whether this message will pass the validation. Just so we can safely say we checked everything. To do so simply create a new test case in which you use an existing file as input for the starting point of your flow. For detailed information on flow testing please check out the Crash Course Platform. This one you should also run to see the results. Once again you are aiming for a blue background or at least that the message passes the validation component.

intermediate-active-monitoring-retest-based-on-received-error-message--result-retest-offramp-test.png

Now that we have passed the validation we can safely assume that our fix worked. The last thing to do is to give the flow in which we changed something a new version so we can deploy it to the proper environment(s). To do so simply navigate to the flow in question and ensure that a new version is created.

4. Key takeaways

  • Retesting is essential to confirm that your changes effectively resolve the error. It ensures your assumptions about the fix are correct.
  • Make sure to test all possible scenarios within your flow to check for any regression issues.
  • By rigorously retesting your implementation, you contribute to higher quality and reliability of the final product, enhancing client satisfaction and trust.

5. Suggested Additional Readings

If you are interested in this topic please read the help text eMagiz provides you and see the following link: