Discussion :

[Graffito]

Pour faciliter l'exécution de tests de non regression sur des IHM Winforms, j'envisage la possibilité d'une automatisation.

Auriez-vous des pistes ou des retours d'expérience ?

[DotNetMatt]

Il existe différents Frameworks, je parlerai ici des Coded UI Tests (qui utilisent l'UI Automation) et qui permettent de faire ça assez simplement. Voici un exemple en vidéo : How Do I: Get Started with Coded UI tests? et voici les best practices : Best Practices for Coded UI Tests.

Sur les écrans qui ne bougent pas beaucoup ou qui sont relativement simples, c'est assez simple à maintenir.
Par contre si tu as des écrans complexes et/ou des écrans qui sont souvent modifiés, il peut être très coûteux d'automatiser ce genre de tests... Si tu es dans ce cas, il peut être judicieux d'y dédier une ressource entière, car ça peut devenir un projet à part entière, occupant une ou plusieurs personnes à temps plein.

Comme autres frameworks envisageables, il y a NUnitForms et Quail. Cependant toute la puissance de l'UI Automation c'est qu'elle est intégrée nativement à Visual Studio, et si tu utilises TFS les possibilités sont assez impressionnantes, au-delà de la simple automatisation des tests...

[Graffito]

Merci de dette réponse.

Par contre si tu as des écrans complexes et/ou des écrans qui sont souvent modifiés, il peut être très coûteux d'automatiser ce genre de tests... Si tu es dans ce cas, il peut être judicieux d'y dédier une ressource entière, car ça peut devenir un projet à part entière, occupant une ou plusieurs personnes à temps plein.

Nos écrans sont globalement complexes (par exemple, 25 formes différentes avec une dizaine de DataGridview, de la visualisation cartographique, ...) et correspondent à un logiciel sur lequel a été consacré 1 année/homme chaque année depuis 8 ans. J'ai un peu peur que la mise en place des tests de non regressions consomme tout un budget annuel, ce qui est inenvisageable.

Sinon, j'avais vu le logiciel "TestComplete" de SmartBear qui me paraissait pas mal (http://smartbear.com/products/qa-too...-applications/)

[DotNetMatt]

En effet, ça peut être problématique de devoir consacrer du budget sur ça. Pour pouvoir décider en connaissance de cause, il faut surtout savoir si ces écrans sont amenés à changer de manière régulière, et combien d'entre eux peuvent être impactés :

• Si peu d'entre eux changent de manière régulière, alors ça peut reste gérable
• S'ils sont tous concernés par des modifications fréquentes alors effectivement il faut budgéter, prévoir de la ressource et voir si ça passe

Concernant le choix de la solution, le mieux ça reste de tester chacune des solutions qui semblent intéressantes, et de voir concrètement ce que ça donne niveau ergonomie, facilité d'utilisation par rapport à la couverture du besoin, etc. Nous avons fait le choix de l'UI Automation car c'est nativement intégré à Visual Studio + TFS. Pas de coûts supplémentaires donc et support natif des technologies Microsoft. Certaines solutions tierces peuvent souffrir de certains manques : le dernier exemple que j'ai en tête, tu mets un bouton sur ton écran. Avec UI Automation, même s'il change de place, pas besoin de modifier le test tant que son nom ne change pas. Avec certaines solutions tierces qui se basent sur les coordonnées des contrôles, il faudra modifier le test, même pour quelques pixels...

Donc voilà le mieux placé pour choisir, c'est toi et ton équipe