Archive for the ‘Uncategorized’ Category

Testlink 1.9 nouvelles fonctionalités

dimanche, avril 10th, 2011

La version testlink 1.9 est sortie depuis la fin de l’année dernière. Elle comporte de nouvelles fonctionnalités intéressantes:

  • Gestion des steps pour les tests
  • Gestion des environnements de tests (un test peut-être passé sur plusieurs environnements)
  • Une meilleure gestion des versions (étendue aux exigences et possibilité de comparer les versions)
  • Amélioration de la gestion des exigences (arborescence à plusieurs niveaux, relation entre exigences)
  • etc…

Plein de nouveautés à découvrir pour cet outil du libre, alternative à Quality Center (HP).

Une fonctionnalité qui m’a plu :

Chaque fois que l’on créé une exigence on peut définir le nombre de tests que l’on pense y associer. Grâce à cette information on pourra suivre la progression de la couverture des exigences par le plan de test, et surtout calculer le reste à faire …

progression couverture des exigences

Forum en anglais sur le test

samedi, janvier 1st, 2011

Il existe un forum en anglais qui permet de poser des questions sur pas mal d’outils de test:

  •  QTP
  • QC
  • Selenium
  • Automated QA
  •  Micro focus
  • JMeter
  • etc …

Traduction du CFTL

jeudi, octobre 21st, 2010

Quelques traductions tirés du glossaire CFTL/ISTQB: 

  • action word driven testing : Test dirigé par les mots-actions 
  •  monkey testing : Test simiesque
  • automated testware : Article de test automatisés
  • moke test: : Tests fumigatoires

  Et vous, vous traduirez comment?

Pourquoi investir dans les tests unitaires … s’il y a des tests systèmes?

lundi, août 30th, 2010

C’est la rentrée … fini les vacances il est temps de reprendre ce blog!Pour remettre les choses en place au boulot une petite formation sur les techniques de test et en passant un rappel sur les tests unitaires les tests systèmes:

  • un test unitaire permet de tester le code, un test système les fonctionnalités offertes.
  • un test unitaire se fait  sur un environnement « mocké » généralement et un test système sur un environnement proche de la production.

Ceci étant dit quelqu’un me demande et pourquoi ne pas investir principalement sur les tests systèmes plutôt que de développer pléthore de tests unitaires qui prennent du temps. L’idée proposée n’est pas de supprimer les tests unitaires mais de les limiter …Voici ma réponse:

  1. l’absence de tests unitaires pénalise les activités de tests d’intégration et de tests systèmes. Le testeur passera son temps à « debugger », faire des aller retours avec le développeur, faire générer des versions plus adéquates et le temps perdu grèvera les tests systèmes de haut niveau (cas d’utilisation, robustesse, scénario complexe). Le « debug » de code est plus rapide lors des tests unitaires en phase de développement. Pour un cycle en V, on court à la catastrophe car le volume de code livré à la validation transformera la phase des tests systèmes en un parcours du combattant pour debugger et mettre au point l’application. De plus les testeurs seront démotivés et fatigués.
  2. Une couverture de code élevée permet d’améliorer la stabilité et la maturité du logiciel. En effet il est illusoire de penser que le test d’endurance ou de robustesse à lui seul va garantir ces caractéristiques. La combinatoire est souvent trop importante pour espérer être exhaustif dans ce domaine. Mais un code testé unitairement permet de contrôler par exemple les exceptions, toutes les branches etc. et donc moins de mauvaises surprises.
  3. Les tests unitaires permettent également de modifier le code de façon sereine en particulier lors de correction d’anomalies et lors la maintenance corrective et évolutive.

Environnements de test

vendredi, juin 25th, 2010

Pourquoi les environnements de test et de développement doivent être séparés?

Il arrive que pour des raisons économiques ces environnements soient communs. C’est un mauvais calcul à court terme et une perte de temps assurée.D’un point de vue pratique il est difficile de partager l’environnement et la gestion de l’accès aux ressources risque de créer des tensions. Si la plateforme est utilisée par différentes personnes en même temps,  l’analyse des problèmes, l’interprétation des logs risquent d’être complexes. Il faudra également s’entendre sur les données de tests. Pendant les phases de test on est souvent amené à redémarrer une plateforme de test. A plusieurs il faut se synchroniser. Bref l’exécution des tests va être laborieuse. Après avoir travaillé pendant quelques mois dans ces conditions j’ai fini par réclamé une machine par testeur pour que chacun puisse travailler de façon indépendante. Ce fût sans conteste un gain de temps inestimable.

D’un point de vue « éthique » exécuter les tests systèmes sur une plateforme de développement est peu recommandé. J’ai constaté que ces plateformes étaient patchées, contenaient des mocks et la base de données pas toujours cohérentes. Dans ces conditions les résultats de tests menés par la validation ne sont pas fiables. Il faut donc un environnement « propre »:

  • installation de l’application en suivant les directives du manuel d’installation que l’on valide par la même occasion;
  • approvisionnement de la base par des procédés valides (éviter les requêtes SQL directes qui peuvent mener à des bases incohérentes).

Vous découvrirez certainement des anomalies qui amèneront cette réflexion habituelle du développeur:

« Et pourtant çà marche chez moi! »,

preuve irréfutable que les environnement de test et de développement sont différents.