Effectivement, j'ai évoqué les rapports d'execution unitaire (utilisé pour comprendre ce qu'il s'est passé dans le cadre de tel ou tel test) mais il y a aussi des dashboards accessible en temps réel sur l'execution d'une campagne de test. Et l'on a branché un outils de reporting externe pour construire des dashboards plus facilement dans un premier temps. Ainsi, on pilote à la fois la qualité de l'application testée, mais aussi la qualité et la fiabilité des tests executés. On n'a pas pensé utiliser un rapport de "duplication de code de test", ce qu'on peut imaginer faire assez rapidement pour mesurer et forcer l'utilisation de la fonctionalité 'useStep' (utilisation d'une Librairie d'action plutôt que réécrire des tests identiques).
On le fait en popote interne pour le moment et on exposera ensuite les API et la doc pour l'utiliser via n'importe quel outil de reporting, voir on en integrera directement dans l'outil.
Pour ta dernière question, la cible est effectivement de s'interfacer au possible à d'autre outils. On favorise pour le moment un integration forte à Cerberus puisque l'enjeu et de rendre les tests rédigeable (et implementable) par un public fonctionnel. Maintenant, je ne connait pas les outils que tu cites, je commence par regarder et je te fait un retour plus précis si tu veux.
[^] # Re: intéressant !
Posté par bcivel . En réponse à la dépêche Cerberus 1.0.0 est disponible. Évalué à 1.
@duf
Merci pour tes proposition.
Effectivement, j'ai évoqué les rapports d'execution unitaire (utilisé pour comprendre ce qu'il s'est passé dans le cadre de tel ou tel test) mais il y a aussi des dashboards accessible en temps réel sur l'execution d'une campagne de test. Et l'on a branché un outils de reporting externe pour construire des dashboards plus facilement dans un premier temps. Ainsi, on pilote à la fois la qualité de l'application testée, mais aussi la qualité et la fiabilité des tests executés. On n'a pas pensé utiliser un rapport de "duplication de code de test", ce qu'on peut imaginer faire assez rapidement pour mesurer et forcer l'utilisation de la fonctionalité 'useStep' (utilisation d'une Librairie d'action plutôt que réécrire des tests identiques).
On le fait en popote interne pour le moment et on exposera ensuite les API et la doc pour l'utiliser via n'importe quel outil de reporting, voir on en integrera directement dans l'outil.
Pour ta dernière question, la cible est effectivement de s'interfacer au possible à d'autre outils. On favorise pour le moment un integration forte à Cerberus puisque l'enjeu et de rendre les tests rédigeable (et implementable) par un public fonctionnel. Maintenant, je ne connait pas les outils que tu cites, je commence par regarder et je te fait un retour plus précis si tu veux.