@Maboiteaspam
Nul besoin de connaitre Java pour utiliser Cerberus, ni pour le déployer.
Ce n'est pas volontairement que l'on ne sait pas interfacé à phantomjs. Pas de raison technique, on n'a pas (encore) regardé.
Essaie de déployer et joues avec, c'est simple de prise en main. Cela ne révolutionera pas ta manière de bosser si tu gères à la fois la définition fonctionelle et le developpement de ton besoin, sur un environnement unique….
Par contre, si tu bosses avec une équipe qui spécifie ses besoins (pour le moment par mail,word ou outil de ticketing), avec tout le "no man's land" que ça implique (les pretexte du genre "j'ai pas pensé à ci", "j'ai oublié ça mais ça coulé de source"…), alors l'utilisation de Cerberus en interface avec eux te simplifiera grandement la vie. Tu l'utilises en complement de spec dans un premier temps, et en les accompagnant, c'est même eux qui implémenteront test tests.
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.
Tu marques un point pour la doc….Je vais mettre ça à jour prochainement.
L'interface web sert à éviter l'utilisation de plusieurs outils. Aujourd'hui, on à tendance à mettre dans la main du métier des outils pour centraliser les cas de tests fonctionnels. Les developpeurs piochent dans ce référentiel et implémentent les tests dans d'autres outils. Cela fait saisir en double ce qui peut être saisie une seule fois, et le fonctionel fini de toute façon par faire ses tests à la main puisqu'il n'a pas de vue sur les tests.
L'interêt de l'interface web dans ce cas est de partager la même vue (Chef de projet + Dev). De plus, pas besoin de développeur pour créer et utiliser des librairies de groupements d'actions. Un fonctionel un peu curieux à rapidement de quoi automatiser ses propres tests, et à les fournir directement aux developpeurs dans le cadre d'une commande d'un nouveau dev.
L'utilisation de l'interface semble à priori plus lourd d'un point de vue Developpeur mais si tu mets bout à bout toutes les actions de clarification dans le cadre d'une recette, c'est finalement plus efficace pour les deux parties.
Pour les tests de navigation, on ne s'interface qu'a Selenium pour le moment. On est en train de s'interfacer à Appium pour venir completer le scope. Cela sera probablement dans une prochaine release.
[^] # Re: intéressant !
Posté par bcivel . En réponse à la dépêche Cerberus 1.0.0 est disponible. Évalué à 1.
@Maboiteaspam
Nul besoin de connaitre Java pour utiliser Cerberus, ni pour le déployer.
Ce n'est pas volontairement que l'on ne sait pas interfacé à phantomjs. Pas de raison technique, on n'a pas (encore) regardé.
Essaie de déployer et joues avec, c'est simple de prise en main. Cela ne révolutionera pas ta manière de bosser si tu gères à la fois la définition fonctionelle et le developpement de ton besoin, sur un environnement unique….
Par contre, si tu bosses avec une équipe qui spécifie ses besoins (pour le moment par mail,word ou outil de ticketing), avec tout le "no man's land" que ça implique (les pretexte du genre "j'ai pas pensé à ci", "j'ai oublié ça mais ça coulé de source"…), alors l'utilisation de Cerberus en interface avec eux te simplifiera grandement la vie. Tu l'utilises en complement de spec dans un premier temps, et en les accompagnant, c'est même eux qui implémenteront test tests.
[^] # 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.
[^] # Re: intéressant !
Posté par bcivel . En réponse à la dépêche Cerberus 1.0.0 est disponible. Évalué à 3.
Merci de ton retour,
Tu marques un point pour la doc….Je vais mettre ça à jour prochainement.
L'interface web sert à éviter l'utilisation de plusieurs outils. Aujourd'hui, on à tendance à mettre dans la main du métier des outils pour centraliser les cas de tests fonctionnels. Les developpeurs piochent dans ce référentiel et implémentent les tests dans d'autres outils. Cela fait saisir en double ce qui peut être saisie une seule fois, et le fonctionel fini de toute façon par faire ses tests à la main puisqu'il n'a pas de vue sur les tests.
L'interêt de l'interface web dans ce cas est de partager la même vue (Chef de projet + Dev). De plus, pas besoin de développeur pour créer et utiliser des librairies de groupements d'actions. Un fonctionel un peu curieux à rapidement de quoi automatiser ses propres tests, et à les fournir directement aux developpeurs dans le cadre d'une commande d'un nouveau dev.
L'utilisation de l'interface semble à priori plus lourd d'un point de vue Developpeur mais si tu mets bout à bout toutes les actions de clarification dans le cadre d'une recette, c'est finalement plus efficace pour les deux parties.
Pour les tests de navigation, on ne s'interface qu'a Selenium pour le moment. On est en train de s'interfacer à Appium pour venir completer le scope. Cela sera probablement dans une prochaine release.