Hello Richard, Unfortunately, the parser looks for the specific string @JREQ- to identify a Jira requirement. However, the requirement keys will be added to tags of the case created - if it helps to map it later. Automation key serves a very specific usecase, that of identifying a case, and it is not recommended to use same key in multiple cases, which would be a case for story or epic id. Hope that helps. Regards, Niharika

Hello Richard, For cucumber, updating steps is possible, since the cucumber.json report contains step details. If you upload the cucumber json, the import call has a flag - bddForceUpdateCase - setting to true, will update the steps if case exists in AIO (either recognized by case key eg. AT-TC-221 or by automation key which is setup in case created by AIO while importing results). For cases where no key or automation key is found, they would be created new. For TS based cases, since there are no Gherkin like steps and only code, only the status of the case can be updated. To sum up: * Upload all of the automated cucumber-cypress, cypress, playwright test cases into AIO. Niharika : Can be done with varying degree of details using different methods as highlihted in the first response * Have them updated if change is happening to the actual test case such as above. Niharika : Supported for Gherkin BDD based frameworks. Not possible for TS based cases [ though APIs for creation/updation of cases are available, if you want to call them in your code] * When we run our daily tests, I want the results to be inside AIO relating to the Jira. Niharika : This is achievable for all frameworks either via APIs or supported reporters. Hope that clarifies. Regards, Niharika

Hello Richard, Here's a summary of how cases can be created from automated cases in AIO 1. Cucumber feature files [Cypress-Cucumber] - a. Feature files can be imported using the Import Feature files flow, wherein each scenario is created as a testcase with steps being reported as BDD steps in AIO. This can be done either via the UI flow or even via API b. Another option to do the same is by using the report file, cucumber.json. While importing, users have an option to set createNewCase as true and cases will be created from the report file itself. However, this flow doesn't support scenario outline cases. 2. Playwright and simple Cypress cases - To import cases, Junit file can be generated while running the cases - both frameworks do support generation. Once generated it can be imported in AIO via Import Results API or via Cycle -> Options -> Import Results, setting the CreateCase as true. This would create placeholder cases in AIO, with the title of the case being set and certain Automation fields being marked. Post creation, for Cypress and Playwright we have reporters, which can help you report results via easy to set config in their respective config files. The cases created in AIO using the above flows, have an automation key set in them, which avoids duplication while usign the same caes again. However, it is recommended to map the AIO case keys in the automated cases . Hope that clarifies your query. Regards, Niharika

Hello Colin, Thanks for bringing this up. The reporter currently doesn't support the steps option. AIO's Cucumber and Robot native integration today support updating steps and creating cases with steps. Are you looking for similar functionality with Playwright steps - that steps in AIO case can be updated with the playwright steps? We would love to hear your thoughts if you have any suggestions. We have also added this to our list to evaluate the options surrounding Playwright steps. Regards, Niharika

Hello Bryan, We had tried putting the Description like you had in our tests and generated the xml. The description still didn;t show up. Can you please let us know how are you generating the report file and the versions being used. Regards, Niharika

Hello Bryan, The Description field in tests, do not make way into the NUnit Test results XML, which form the input to AIO. [ Ref : https://docs.nunit.org/articles/nunit/technical-notes/usage/Test-Result-XML-Format.html] AIO APIs are always an option to make call from your code to update description from test frameworks. Another option can be to establish a new convention in property, say "AIO_Description:" and since properties do make their way in the results file, AIO can parse it as description. This can work for new cases, but for existing cases, this may add extra work. We would like to hear your opinion on this approach or of any other suggestions as well. However, for the category, they can definitely be tagged in AIO Tests. We will add a feature request for this and update this thread as this is gets released. Regards, Niharika

Hello Cameron, Thanks for adding more context. Can you please let us know which report are you using? Or are you using the group by on cycle details page? Regards, Niharika

Hello Cameron, Today, AIO Tests doesn't store a mapping between what sets were used to create a cycle. And hence the display shows all sets where the cases belong. It would also be a challenge for AIO Tests to make a decision on which sets to show or not to show. Would grouping by folder/component in reports be a better view in your scenario? Regards, Niharika

Hello, The management of cases and sets is perfect.  When the same case belongs to multiple sets, and if these sets are used to create a single cycle, the cases are added only once. So, this should not cause duplicates. Are the sets being used to create different cycles from the sets (one from regression set and one from story set)?  Or are the cases being used as linked cases? Can you please elaborate the scenario, so that we can better understand the issue and suggest. Regards, Niharika

Hello, Gauge-selenium can be supported either via the JUnit report or via AIO REST API calls in the setup/teardown hooks. AIO Tests supports parsing the JUnit report for results and can directly import status, duration and errors from the results file. Results file can be sent to AIO using the Import Results API call or via our Jenkins or ADO plugins. If more details are required, like step level results, actual results, attachments and more, then AIO REST APIs listed here can be invoked. Hope that helps. Regards, -N

Hello Andrew, Currently there is no direct integration with Ranorex. If Ranorex does support calling REST APIs and has shutdown hooks, then AIO APIs can be called and results can be reported against tests. We are evaluating the tool and it's usage ,for the possibility of extensions. Regards, -N

Hello Mark, The JUnit xml report is pretty basic in the data that it captures. Getting data into the actual result which is at step level, is not possible, since there are no step level results. Also, there has to be a mapping between the step and the code. If you would like to get granular control over each step result, then the way to go would be the AIO Tests REST APIs. Check out the update detailed result API : https://tcms.aiojiraapps.com/aio-tcms/aiotcms-static/api-docs/#/Execution%20management/updateDetailedRunResult HTH. -N

On closer look - (looked really hard 😀) , the issue seems to be The address seems to be incorrect - tcms.aiojiraapps.com is the correct one. It seems there is an extra ‘a' and a 'p' less in 'apps' in the URL address . Regards, N

Hello David, Are the calls from UI and Swagger being made from the same machine as the Playwright calls or is it being called from some CI/CD server? Regards, N

Automation keys are used in the absence of case keys to identify a case. In case of Junit, TestNG, the fully qualified name ie classname.methodname (eg. com.aio.auto.samples.TestNGDataProviderTests.mixDPTest). makes the automation key. In case of cucumber, the scenario id in the cucumber.json makes the automation key. AIO parsers need some value from the result files [ generated by frameworks ] to search in AIO db in absence of case keys and hence these conventions differ by framework since each framework generates a different result file and we need to pick something which is gauranteed to be there in the report. If you could let us know your framework details, we can let you know specifics on that. Regards, N

Hello @cameron.fairburn , Apologies for missing this. If we automatically set the automation keys to the case keys, then on re-indexing, the automation key may be, say AT-TC-12 and the case key may have reindexed to AT-TC-10. Now there can be another case, which has been newly reindexed to the case key - AT-TC-12. When a user marks the tag of the case as AT-TC-12, we would get to two cases , one with automation key as 12 and one with case key as 12. This would cause a problem and incorrect cases will be updated. Even if the functionality was given, then after running the utility, the casekey and auto key would become AT-TC-10 and the automation case in the automation repo would still be pointing to AT-TC-12. So, in both cases, this solution wouldn't work. However, we do understand reindexing creates a problem with automation and will discuss internally if a solution can be provided to address it. Regards, N

Hello @Keith, There are two ways to report results from the pytest framework. 1. Pytest is capable of generating Junit report, which can be imported in AIO and the results can be read from the file. To send the report one of AIO Tests APIs can be used or you can use one of our plugins like the Jenkins or the Azure Devops plugins, in case you are using them for CI/CD 2. AIO Tests APIs can be directly called in after hooks of the framework if available. Hope that hepls. -Niharika

Hello Cameron, Automation keys created by AIO on import results are normally fully qualified names corresponding to code structure. Putting the test key as automation key seems to be a very specific use case. One of the ways to achieve this is to use the APIs to update the automation key. You can reindex and then use the REST APIS of Get Case and Update Case to update the automation key to the latest case key. Hope that helps. -N

@arun thakur The media type multipart/form-data is the preferred media type for request payloads that contain files, non-ASCII, and binary data. And hence all file related APIs in AIO are multipart form data. All REST client libraries have detailed documentations to support this format. eg. Axios in Javascript. Resteasy, Jersey in Java. Requests in Python. REST API calls can be made from any framework in the after hooks. HTH. Regards, N

@arun thakur Here's a detailed link for integration of webdriverIO : https://aiosupport.atlassian.net/wiki/spaces/AioTests/pages/2027389127/WebdriverIO+Mocha Documentation link for AIO Tests : (search box can help you with searching for any topic of interest) https://aiosupport.atlassian.net/wiki/spaces/AioTests/overview Code samples: https://aiosupport.atlassian.net/wiki/spaces/AioTests/pages/2037022736/Code+Samples HTH. Regards, N