implemented retry_type checks used in the TestClass

[mskarayigit]

retry_type variables in the TestClass now check within the retry_prompt in the Sequencer.py

• RT_ABORT : Abort the whole test sequence after all attempts have failed
• RT_RETRY : Automatically retry up to "attempts" and then prompts the user for the options (Retry, Abort, Fail)
• RT_PROMPT : is the default in the TestClass, Prompt the user; Options are Abort the sequence, retry, or fail and continue (currently has the same functionality as RT_RETRY)
• RT_FAIL : Automatically fails and moves on onto the next test if all the number of attempts have failed.

Also, added a test script under test.

[skarayigit]

The attempts variable in the TestClass has been configured to automatically retry a test case when a failure occurs. This functionality is working as intended. However, an additional requirement is needed to allow the overall test sequence to continue executing on the remaining circuits even after all retry attempts for a particular test have been exhausted and the test ultimately fails.

This approach would enable the generation of a comprehensive test report at the end of the execution, identifying all failed circuits without requiring operator intervention or waiting for user input. As a result, any necessary rework can be performed on all failed circuits in a single batch, improving efficiency and avoiding the need to repeatedly repair and retest individual circuits one at a time.

In some situations, test failures may be caused by transient issues such as instrument switching delays or measurement timing variations. In these cases, one or more retry attempts may successfully recover from the issue and result in a passing test outcome.

Conversely, certain test cases may be associated with critical circuits or dependencies that are essential for downstream testing. For these scenarios, it should be possible to configure a maximum number of retry attempts and, if the test continues to fail after all retries, terminate the test sequence. This prevents subsequent tests from being executed when their results would no longer be valid due to the failure of a critical prerequisite circuit.

Therefore, the test framework should support both behaviors:

Non-critical tests (RT_FAIL): Continue testing the remaining circuits after all retry attempts have failed, and record the failure for reporting purposes.
Critical tests(RT_ABORT): Abort the test sequence when all retry attempts have been exhausted and the test still fails, preventing invalid downstream testing.

RT_PROMPT is still a default behavior and prompts the user after all attempts have failed with options (RETRY, ABORT, FAIL)

This flexibility would improve test efficiency, reduce operator involvement, and provide more meaningful test reports and failure analysis.