Archive for the ‘G’ Category

Changement de CMS

dimanche, septembre 18th, 2011

Je vais changer de CMS dans les jours qui suivent. Vous serez sans doute, si vous le désirez, obligés de vous réabonner au flux RSS.

Veuillez m’excuser pour le désagrément.

Dominique.

Popularité des outils open source dédiés test

vendredi, décembre 17th, 2010

Il y a eu plusieurs discussions au sujet des outils open source (gestion de test et gestion de bug) sur Linkedin, sur le groupe « Software Testing and Quality Assurance ». Un professionnel du test, Vinodh Velusamy, a une l’excellente idée d’en faire une compilation et de mesurer à travers les réponses la popularité de ces outils dans la communauté des testeurs. Je vous livre les résultats de ces mesures. Vous pouvez lire l’article complet dans le numéro 12 du magazine « Testing expérience » .

 

En ce qui concerne les outils de BugTracking :

1/ Bugzilla 60%

2/ Mantis 30%

3/ Trac 5,5%

4/ Bugtracker 3%

 

 

En ce qui concerne les outils de gestion de test :

1/ Testlink 53%

2/ Testopia 17%

3/ Redmine 12%

4/ RTH 7,5%

5/ Xqual XStudio 6%

 Vous retrouvez l’article original et bien d’autres sur les outils open source dédiés au test ici.

Bonne lecture

publication d’un article sur la testabilité

mercredi, mai 19th, 2010

Je viens de publier un article qui propose des pistes pour améliorer la testabilité d’un projet sur developpez.com. Je vous invite à le consulter ici: testabilité.

Un forum dédié test

mercredi, avril 7th, 2010

Des questions,  des réponses sur le test:

Faites un tour sur le forum:le forum des testeurs

Article sur Model Based Testing paru dans methods and tools

vendredi, avril 2nd, 2010

Method and tools vient de faire paraître dan son édition de printemps un article intéressant sur le Model Based Testing. L’auteur présente la démarche et en souligne la principale difficulté:  concevoir le modèle. Mais cette réflexion sur le modèle est également le moyen le plus efficace de revoir et améliorer les exigences. Retrouvez son analyse içi!

Descriptif du numéro:

  • Using WatiN to Leverage Common Elements in Web Testing
  • Five Symptoms of Mechanical Agile
  • Writing Testable Code
  • Model-Based Testing Adds Value
  • Tool: Sonar
  • Tool: Express – Agile Project Management
  • Tool: Apache JMeter

Bonne lecture.

Software Testing Europe

mercredi, mars 31st, 2010

Un nouveau site dédié aux offres d’emploi dans le métier du test est né.  En bonus un IPAD à gagner si vous vous inscrivez dans les premiers !!!

Alors à vos CVs!
Software Testing Europe

portail sur le test

lundi, décembre 7th, 2009

Dans Infos Test le lien « Blogs, Sites, Outils sur le test » mène à un portail qui référence des blogs, des outils et des forums liés au test. J’essaie de mettre à jour ce portail au fur et à mesure de mes découvertes. Pour l’instant il s’agit plutôt de lien mais je compte enrichir le site avec des descriptions plus complètes. Si vous connaissez d’autres outils n’hésitez pas à m’en faire part je les rajouterai.

Les bonnes pratiques du test.

samedi, novembre 28th, 2009

Avoir un environnement de test « propre » est un pré requis à une campagne de test. Mais quand monter un environnement de test prend du temps et est complexe, la tentation est grande de ne pas tout faire dans les règles. Pourquoi ne pas prendre l’ancien environnement et le bidouiller un peu pour la prochaine campagne car c’est moins couteux en temps?

Quels sont les risques:

  • J’ai rajouté manuellement un champ dans une table de la base de données et j’ai également mis les données  dans cette base. Tout fonctionne correctement. Malheureusement le dba a oublié de rajouter ce champ ou n’a pas mis exactement les mêmes données. Conclusion en production rien ne fonctionne.
  • La structure d’un fichier de configuration a évolué, je l’ai modifié manuellement. Tout fonctionne correctement lors de mes tests, malheureusement l’installation n’a pas été modifiée, uniquement le code pour s’adapter à cette nouvelle structure. Conclusion une fois en production il y a une erreur au lancement du programme.

D’un coté les tests sont faits plus rapidement car on a gagné du temps sur la mise en place de l’environnement de test, mais en final on en a perdu beaucoup à chercher l’erreur en production sans compter les problèmes de confiance par la suite. Là l’équipe de test peut ruiner son image: « Ce logiciel n’a jamais été testé! ».

En conclusion:

  • Avant de livrer les tests doivent être effectués sur un environnement propre (tout réinstaller). C’est la garantie d’une livraison saine.
  • Un programme d’installation simple et rapide incitera les testeurs à ne pas prendre de risques.
  • Ne jamais oublier qu’une erreur est vite arrivée (oubli, manque de coordination …) même quand il s’agit de modifications à priori simples.

Définition du test de stress logiciel

vendredi, novembre 6th, 2009

Après de vives discussions sur la définition du test de stress dans ma société je vous fait part de ce que j’ai glané sur le net:

Sur un site proposant des services de test:

« Stabilité et stress: Un test de stress est l’analyse du comportement d’un logiciel lorsqu’il est soumis à des cas de non conformité des applications.  …
Le test de stress permet de révéler le comportement de l’application et prévoir les causes afin de fiabiliser votre logiciel.  »

Sur un pdf  de Raymond Rivest
Conseiller, spécialiste de test, CRIM Centre de tests du logiciel:

Tests de charge, de stress et de configuration
Afin de déterminer les goulots d’étranglement et la stabilité du système, des tests de charge et de stress sont exécutés. La principale différence entre ces deux types de test est la suivante :

  • Un test de charge comporte un scénario de base, pour lequel le volume de transaction et d’usager sera augmenté de manière graduelle.
  • Un test de stress consiste à exécuter un scénario de charge maximale du système sur une période maximale.

Pour le test de charge, il s’agit de déterminer à quel moment le système ne sera plus conforme aux performances requises ou que des erreurs surviendront. Pour le test de stress, il s’agit de déterminer combien de temps le système peut supporter la charge maximale sans entraîner de corruption de données ou cesser complètement de fonctionner.
Une fois les goulots identifiés, on procède au dimensionnement du système en fonction des objectifs de performance requis. Les composantes du système seront ajustées, ainsi que les configurations, de façon à obtenir le meilleur rendement. »

Autre définition sur un site web www.qualitelogicielle.com:

« Tests conçus pour déterminer si le système peut fonctionner avec un large volume -plus large que normalement attendu.
–Les zones de stress incluent : transactions, tables internes, espace disque, données de sorties, données d’entrées, communication, capacités de l’ordinateur, interaction avec les ressources, etc.
–On assure de pouvoir traiter x transactions par minute, mais jusqu’où le système peut-il en accepter? Documenter le point de rupture.  »

Définition trouvée sur wikipédia:

« Test de stress : il s’agit d’un test au cours duquel on va simuler l’activité maximale attendue tous scénarios fonctionnels confondus en heures de pointe de l’application, pour voir comment le système réagit au maximum de l’activité attendue des utilisateurs. La durée du palier en pleine charge, en général de 2 heures, doit tenir compte du remplissage des différents caches applicatifs et clients, ainsi que de la stabilisation de la plateforme de test suite à l’éventuel effet de pic-rebond consécutif à la montée en charge. Dans le cadre de ces tests, il est possible de pousser le stress jusqu’à simuler des défaillances systèmes ou applicatives afin d’effectuer des tests de récupération sur incident (Fail-over) ou pour vérifier le niveau de service en cas de défaillance. »

Définition de l’ISTQB:

« Test de stress : Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduites de ressources telles que l’accès mémoire ou serveurs [d’après IEEE 610]. »

Toutes ses définitions se ressemblent et sont assez différentes en fonction du point de vue performance ou stabilité.

Conditions de test:

  • Charge au delà de la normale
  • Multi scénario.
  • Ressources réduites, conditions anormales.

Objectifs:

  • Stabilité et fiabilité du logiciel.
  • Point de rupture du logiciel, goulot d’étranglement.
  • Mesures pour réaliser le tuning de l’application.
  • Niveau de service en cas de défaillance.
  • Mesure du temps de récupération après défaillance.

Finalement quelque soit le nom l’important est de vérifier tous les points précédemment cités.

Contenu de « Methods & Tools »

samedi, octobre 3rd, 2009

Dans le numéro de cet automne vous trouverez l’ article suivant:

Implementing Automated Software Testing Continuously Track Progress-And Adjust Accordingly de Thom Garett (Innovative Defense Technologies).

Cet article présente des métriques qui vous permettront d’évaluer votre process d’automatisation et éventuellement de le rectifier (comme par exemple votre choix de tests à automatiser). Vous trouverez cet article au lien suivant: article.
Bonne lecture.