Je pense que la volumétrie du projet testé est aussi à prendre en compte et comme tu le dis dans ce cas une stratégie supplémentaire doit être de mise.

Très bonne article.

Normalement, sans pb:
http://www.targetprocess.com/blog/2007/04/selenium-usage-in-real-life-aspnet-20.html
http://www.stevetrefethen.com/blog/AutomatedtestingofASPNETwebapplicationsusingSelenium.aspx

Tiens, d’ailleurs, ca me fait penser que je devrais peut-être essayer de le mettre en place aussi

Dans notre cas, vu que nous sommes dans notre environnement habituel, on a, spécifiquement sur la machine de recettage, la possibilité de réinitialiser les données applicatives de test (créations des utilisateurs et de leurs profils par exemple).

Concernant les valeurs testées, nous faisons assez light pour l’instant, avec en général que peu de variations (on fait des tests d’intégration, les variations sur des valeurs sont plutôt côté tests unitaires). Du coup le jeu de test en tant que tel n’est pas trop d’actualité. Toutefois, la bonne nouvelle, c’est qu’on est toujours « totalement » dans notre contexte : de l’excel est possible, mais aussi de passer par une DB dédiée, des fichiers XML, des propriétés… Au demeurant, il se peut que des collègues aient déjà développés des jeux de données à la demande de product owner sans que je le sache…

Histoire de faire « contre poids », nous on utilise Selenium avec grand bonheur. La réalisation des scripts via le plugin firefox marche bien, puis pouvoir générer la chose dans le langage de son choix pour ensuite optimiser la bête est vraiment tip top.

Côté poste du développeur, cela donne une classe de test jUnit spécifique qui s’occupe de lancer un serveur web sur un port libre, ainsi que l’environnement Selenium requis (server + remote control). Cela s’intègre donc dans eclipse comme un charme, ce dernier considérant ces tests comme n’importe quel test jUnit (même si dans ce cas il ne s’agit pas de tests unitaires, cela aide tout de même à l’utilisation).

Ensuite ces tests d’UI en Java sont lancés automatiquement (intégration continue) via hudson, ce petit bijou permettant d’avoir les différents environnements (windows/linux) lancés en parallèle de façon « transparente ».

Concernant le prix, et dans une certaine mesure l’aspect open source, je pense que cela a son importance : un produit propriétaire ne sera que peu intégré dans des produits tiers, d’autant plus s’il est cher.

De plus, le prix est une barrière à l’adoption/démocratisation de tels produits, alors qu’ils devraient être communs en informatique.

Enfin, comme avec nombre de produits open source, l’intégration de Selenium s’est avérée des plus aisées et souples.

Concernant QTP, je n’ai que participé à une étude préliminaire en vue de sa mise en pratique dans une grande banque française (je ne connais pas les raisons de ce choix de produit), mais l’impression qui s’en dégageait était une certaine lourdeur, notamment pour utiliser des jeux de données pour les tests.

Maintenant je ne suis pas allé plus loin sur ce projet : je vais voir si je peux avoir des retours d’expérience pour ceux qui ont dû le mettre en pratique.

++

Mais c’est clair que ces questions sont nécessaires, et ce quel que soit l’outil

(au fait, il manque un espace dans ton titre )

* Phase 0: There’s no difference between testing and debugging. Other than in support of debugging, testing has no purpose.
* Phase 1: The purpose of testing is to show that the software works.
* Phase 2: The purpose of testing is to show that the software doesn’t work.
* Phase 3: The purpose of testing is not to prove anything, but to reduce the perceived risk of a software not working to an acceptable value.
* Phase 4: Testing is not an act. It is a mental discipline that results in low-risk software without much testing effort.

La phase 4 consiste plutôt à optimiser les tests tout au long du cycle de vie, donc à tester le plus tôt possible. Toute l’organisation doit être impliquée, la qualité n’est pas réserver aux équipes de validation. C’est aussi porter les effort de test là ou le risque de bug est important ou la fonctionnalité est critique. On part du principe que tester de façon exhaustive est impossible il faut alors trouver la stratégie qui permettra de réduire le risque de bug à moindre frais.

Posté dans Généralités |

http://se.ethz.ch/~meyer/publications/computer/quality_first.pdf