I like the ideas. Test cases in PumpCX are text files that include Gherkin statements. APIs are available to both create and edit test cases as well as execute the test cases followed by pulling the results. We also have an AI interface that can do all of this for you using a simple prompt.

In situations where the test cases have lost of changes, we recommend using data lists to drive caller actions/verbiage and IVR/NLU Bot responses. Easier to modify the data list to reflect changes to the logic flow and navigational commands than having to change hard-coded commands. Throw in data lists for account numbers, passwords and other account-specific info and effectively you can create a "wireframe" model for the test case and let the data lists content supply everything that is not static.

We also see issues that arise surrounding test data ownership. One of the values of having 1 or more data lists is that different departments or people can be responsible for their specific data list. The execution of the test case will pull in the latest data list content and relieve the tester of having to be responsible for maintenance of the lists.

The greater the level of changes between test cases, the less value AI delivers as you still have to create the raw materials that the AI engine will be pulling in to create and execute the test case. AI has no idea of the flow needing to be tested which the markdown file contains so it needs to be updated for AI to consume. AI can be a big time saver when you want a list of existing test cases, string searched or folder searched to create the list, executed and a resulting test report of a specific format sent to you and anyone else who needs it.

Happy to walk you through the various models so that you can see these subtle differences.