Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

06 juillet 2010

Le glas sonne pour les environnements d'essais traditionnels

Au Better Software Conference 2010, à Las Vegas en juin dernier, j'ai assisté à une présentation de Ken Johnston, le gestionnaire des essais pour l'engin de recherche Bing de Microsoft.

 

Essentiellement, Johnston nous dit que l'avènement du "cloud computing" sonne le glas de nos laboratoires/environnements d'essais traditionnels. Dans le contexte actuel, où ces environnements sont dispendieux et jamais exactement comme ceux de production, il est opportun de se questionner sur leur avenir. Les architectures de services, qu'il s'agisse de SaaS, PaaS ou de IaaS implanté sur un nuage public, privé ou communautaire ou hybride complique les essais. De plus en plus, nos solutions vont utiliser des services de tiers pour lesquels on a pas d'environnement d'essais. Alors, pourquoi ne pas tester directement en production?

 

A tout le moins, on peut considérer le cloud pour héberger les environnements d'essais traditionnels. En effet, pourquoi acheter des machines physiques quand on peut les obtenir dans le nuage sous forme de IaaS (infrastructure as a service).

 

Johnston mentionne que nos pratiques d'essais s'appliquent aussi aux services et au cloud, parfois sous un angle différent. Il indique que les principaux impacts se font sentir sur les environnements d'essais (virtuel), sur le fait que les déploiements doivent être eux-mêmes testés, qu'il faudra parfois utiliser des approches d'émulation et éventuellement gérer des essais directement en production.

 

Johnston insiste beaucoup sur le fait que le déploiement doit être automatisé et doit se faire essentiellement avec une ligne de code. Cette pratique est supportée par l'intégration continue utilisée en développement.

 

Les pratiques d'essais en production sont nouvelles dans le monde informatique, mais on les retrouve aussi dans d'autres domaines, on pense par exemple aux essais cliniques des médicaments conçus par les pharmaceutiques, aux essais en vol effectué par les pilotes d'essai, où aux modifications apportées aux réseaux de télécommunication cellulaire.

 

Johnston offre 12 conseils pour tester en production :

à        Mettre la machine de test dans le centre de traitement

à        Faire des beta en production (beta perpétuel)

à        Plusieurs versions en production, en parallèle

à        Expérimentation avec groupe de contrôle (A/B test)

à        Tester de façon continue

à        Tester et monitorer

à        Tester l'intégration en production

à        Tester la performance et la capacité en production

à        Tester le centre de traitement

à        Tester la continuité de service

à        Rouler la couverture de code sur une partie de la prod

à        Inclure des hooks de test en production

 

Pour en savoir plus :

Chapitre 14 de son livre "How we test software at Microsoft", disponible sur le web : http://www.docstoc.com/docs/23309271/How-We-Test-Software-at-Microsoft

 

http://blogs.msdn.com/b/kenj/archive/2009/11/24/tip-ing-services-testing-blog-1-the-executive-summary.aspx

 

http://exp-platform.com/Documents/2009-09%20ExP%20SeattleTechStartup.pdf

15:45 | Lien permanent | Commentaires (0) | Tags : test

05 octobre 2007

Tests dans VisualStudio Suite

Hier j'ai jeter un coup d'oeil à VisualStudio pour voir le genre d'outil de test intégrés, toujours dans le but de faire du TDD (Test Driven Development) et en particulier d'automatiser les tests pour l'acceptation des users stories.

Dans VS2005 il est possible d'ajouter une projet de test à une solution. Dans ce projet de test il peu y avoir divers type de tests: web, unitaire (unit), charge (load testing) et même des tests manuels. Comme j'avais installer TestComplete, VS2005 permet même de créer ces tests à l'intérieur de VS. Donc intéressant d'un point de vue développeur, mais pas ce que je cherche pour tester nos applications XBAP.

Donc pour le moment QuickTest Pro semble le meilleur choix.

03 octobre 2007

Test des applications WPF et XBAP

Idéalement j'aimerais avoir des tests automatisés pour toutes les users stories que nous développons, dans le style de ce que FIT/FITnesse, Selenium ou GreenPepper fait. Mais voilà, il n'existe rien pour le moment qui supporte les applications WPF ou XBAP. Il n'y a rien qui soit user friendly et qui viserait le pilote du système (client). Bien sûr il est possible de tester les services web, mais je veux attendre un peu avant d'introduire plus de code.

 Du coté de l'interface il ne semble y avoir que "QuickTest Pro" de Mercury, iSimplyTest de Invivo Software et TestComplete de Automated QA.

J'ai installé QuickTest pro et j'ai lancer le produit. Première constatation, ça n'a pas l'air simple. Après quelques minutes je constate que je dois installer le add-in pour .NET si je veux enregistrer les événements dans WPF/XBAP. J'ai fait des tests avec l'application xbap "wiki explorer" et ça fonctionne relativement bien. Par contre un test avec le features explorer de la grille xceed semble montrer que QTP ne reconnait pas les controles. Avec Infragestics ça a l'air de mieux être reconnu.

iSimplyTest est une concept intéressant mais très peu évolué et qui requiert du code, donc pas ce que je recherche. Ca semble être une bonne facon d'apprendre le "UI automation" de WPF.

J'ai aussi essayer TestComplete très sommairement. Comme la vue tourne autour du code, ce choix m'apparait moins intéressant pour nos besoins.