Updating the counters in the TAG table following manual tests

[InkUisitor]

Bonjour à tous,
Je suis actuellement sur une version 4.20 de Cerberus. Je suis dans un contexte hybride avec des tests manuels et automatisés. J'ai pu constater que les compteurs de la table Tag n'étaient pas mis à jour pendant des phases de tests où le testcase avait comme valeur WE et qu'il passait à une autre valeur pendant une exécution manuelle d'une campagne.
Après avoir cherché, j'ai constaté que la fonction updateEndOfQueueData n'était utilisée qu'aux modifications d'un testCaseExecution d'une Queue et je creuse, mais il semble que ça ne soit lié qu'aux tests automatisés. De ce fait, les rapports d'exécution manuels n'affichent pas des données correctes : pas mal de datas figées, les score CI qui sont incorrects.
Est-ce qu'il serait intéressant selon vous de permettre l'utilisation de cette fonction pour mettre à jour les infos de la table Tag lorsqu'on sauvegarde l'exécution manuelle d'un scénario manuel ?
Merci pour vos réponse !

---

Hello everyone,
I am currently using version 4.20 of Cerberus. I am working in a hybrid environment with manual and automated testing. I noticed that the counters in the Tag table were not updated during test phases where the test case had a value of WE and changed to another value during manual execution of a campaign.
After some research, I found that the updateEndOfQueueData function was only used when modifying a testCaseExecution in a Queue, and I am looking into it further, but it seems that this is only related to automated tests. As a result, manual execution reports do not display correct data: a lot of data is frozen, and CI scores are incorrect.
Do you think it would be useful to allow this function to be used to update the Tag table information when saving the manual execution of a manual scenario?
Thank you for your answers!

[InkUisitor]

Bonjour @vertigo17
Je viens d'ajouter cette portion de code à la fin de void updateTestCaseExecutionFromJsonArray(JSONObject testCaseJson, ApplicationContext appContext, String user) :

// Update Tags table with end of queue data using the tag from TestCaseExecution
String tag = executionToUpdate.getTag();
if (tag != null && !tag.isEmpty()) {
    org.cerberus.core.crud.service.ITagService tagService = appContext.getBean(org.cerberus.core.crud.service.ITagService.class);
    tagService.updateEndOfQueueData(tag);
}

J'ai contrôlé le comportement et ça me semble OK. J'ai également vu que ce call (et les fonctions sous jacentes) n'était effectué que par TestCaseExecution.js donc je pense qu'il n'y aura pas de side effect avec cette modification de code.
J'ai réalisé cette modification à partir du tag de la dernière version buildée pour Docker 4.20 (testé sur une image Docker bidouillée).
Je viens de créer une Pull Request avec la modification réalisée.
Bonne journée

[InkUisitor]

J'ai update mon code qui était un peu cracra

[vertigo17]

Hello.
Sorry for coming back a bit late on the subject.
For that fix I need to explain you a bit why this is not as simple ;-).

The KPI counters on tag table are saving the state of the campaign as soon as it is closed (at the end of the last automated execution is performed and when no more queue executions are detected). That also correspond to the event when the CICD is released with final status of the campaign.
If some executions are performed after that, we no longer update those fields in tag table because we want to be able to follow the stability of the campaign in full automated mode. We also want to keep track the detail KPI values that correspond to the final Campaign status.
If we update them after a manual or automated execution that is triggered after the end of that event, the result will more be based on the time spend by QA team on relaunching those executions rather than the stability of the campaign in full automated mode.
As a consequence, for that fix, we should more:
1/Duplicate all KPI field into separate columns (named live values vs the current values that I will call automated values).
2/At the end of every automated executions we update both live and automated values (today only automated are).
3/ When a manual update on an execution is performed, or new execution triggered after the queue has been empty, we should only update the live values leaving the automated KPI unchanged.

The changes will be a bit more important.

[InkUisitor]

J'ai effectué des recherches car entre plusieurs exécutions de campagne, j'ai eu des comportements différents. Voici le résultat de mes recherches :

• après avoir lancé une campagne manuelle, la table "testcaseexecutionqueue" va affiche des test case avec un State à "EXECUTING" sur des tests manuels
• ces tests case ne changent jamais au State "DONE" même après avoir exécuté ces tests case manuellement. Le controlstatus dans la table "testcaseexecution" est correctement sauvegardé pourtant "OK", "FA", ...
• après un laps de temps, un traitement va finir par passer les "EXECUTING" en "CANCELLED" malgré le fait qu'une campagne a été terminée
• de nombreuses data ne seront jamais modifiée : Tab.nbExe, tab.nbExeUsefull, tag.DateEndQueue, tous les CIScore, CIResult. Ces datas ne sont jamais calculés du fait que la queue n'est pas complètement DONE sur cette campagne et donc pas d'utilisartion de la fonction updateEndOfQueueData dans son schéma standard et attendu

J'ai remarqué qu'en lançant une première campagne, j'avais ces status EXECUTING activé, mais en quand j'en lance une seconde, celle ci n'est pas victime de ce comportement.
Est-ce un bug lié à un traitement de la queue ou quelque chose que je rate concernant un éventuel paramétrage ?
Merci pour la réponse. J'ai fermé ma pull request car je comprenais que ma vision était plus un pansement qu'une véritable correction.

---

I carried out some research because I observed different behaviours between several campaign runs. Here are the results of my research:

• After launching a manual campaign, the "testcaseexecutionqueue" table displays test cases with a "EXECUTING" status for manual tests
• These test cases never change to the "DONE" state, even after running them manually. The controlstatus in the "testcaseexecution" table is correctly saved as "OK", "FA", etc.
• After a period of time, a process will eventually change the "EXECUTING" status to "CANCELLED" despite the fact that the campaign has been completed
• Much of the data will never be updated: Tab.nbExe, tab.nbExeUsefull, tag.DateEndQueue, all CIScore and CIResult values. This data is never calculated because the queue is not completely DONE for this campaign, and therefore the updateEndOfQueueData function is not used in its standard and expected manner

I noticed that when launching a first campaign, I had these EXECUTING statuses active, but when I launch a second one, it is not affected by this behaviour.
Is this a bug related to queue processing, or am I missing something regarding a possible configuration?
Thank you for your reply. I have closed my pull request as I realised that my approach was more of a workaround than a genuine fix.

[vertigo17]

OK. Ce que tu decris ressemble à un bug. J'essaie de reproduire pour comprendre mais une execution en mode manuel dans une campagne devrait effectivement passer par un status EXECUTING mais quasi instantanément basculer en DONE des que l'execution a été générée par le moteur.