Tests de sécurité applicatifs

25 05 2009

La sécurité des SI est un sujet important pour toutes les DSI depuis de nombreuses années déjà. Les tests en font partis. Par conséquent une très grande quantité de société propose des tests de sécurité et d’intrusion ou bien des audits permettant de connaitre les vulnérabilités d’une entreprise afin de les « corriger ».

Mais dans ce petit monde je ne connais personne ne traitant réellement, concrètement et opérationnellement des tests de sécurité applicatifs !

C’est pourquoi j’entame des nouveaux articles sur le sujet afin de vous en faire profiter. Si vous avez de remarques ou des suggestions je suis à votre écoute.

Mon premier article traite d’une de mes visites chez HP où assisté à la présentation des mises à jour majeures de ses logiciels conçus pour aider les DSI à réduire la vulnérabilité de leurs applications Web. Ces nouvelles offres font partis de HP Application Security Center, une suite de logiciels et de services conçue pour aider les entreprises à assurer la sécurité de leurs applications Web en leur permettant de découvrir, corriger et prévenir des vulnérabilités susceptibles d’être exploitées par des pirates.

Qu’est-ce que HP Application Security Center ?

Il aide les développeurs, les équipes d’assurance qualité et professionnels de la sécurité à détecter et corriger rapidement et de façon rentable les vulnérabilités et anomalies tout au long du cycle de vie de l’application. Ces produits logiciels de test de la sécurité fournissent des définitions de stratégie sécuritaire communes, des tests de sécurité automatisée, un contrôle centralisé des autorisations et un accès Web aux informations de sécurité.

Les nouveautés 2009 :

HP Assessment Management Platform 8.0 – aide les entreprises à réduire les coûts et les risques applicatifs via une plateforme de test distribuée et évolutive de sécurisation des applications web.

De plus, HP Assessment Management Platform 8.0 permet aux entreprises de :

  • Prioriser les problèmes de sécurité en fonction des objectifs métiers. De nouvelles fonctions analytiques aident les entreprises à identifier les actifs qui ont besoin d’être sécurisés et à classifier les données suivant leur importance pour l’activité de l’entreprise. L’intégration d’un contexte métier aux données permet de concentrer efficacement l’attention des ressources compétentes en sécurité
  • Sécuriser plus d’applications avec moins de ressources spécialisées à l’aide d’un modèle des services partagés. Ce dernier est apporté par des fonctions de reporting globales ainsi que par une nouvelle fonction de visualisation permettant à des équipes de superviser à distance un scan de sécurité

HP WebInspect 8.0 – aide les entreprises à analyser en profondeur les applications web complexes. Cette nouvelle version apporte plus de rapidité et de fiabilité dans les tests et les capacités de remédiation (terme employé par HP signifiant « trouver un remède » – n’existe pas dans le dictionnaire français) de la sécurité des applications web, y compris celles développées avec des technologies Web 2.0.

HP Software-as-a-Service (SaaS) Project Services for Application Security Center permet aux entreprises de mettre rapidement en œuvre leurs initiatives de sécurisation des applications via une solution complète, maintenue et administrée par HP.

Les nouvelles offres de HP permettent aux DSI de prioriser les menaces en fonction de leurs objectifs métiers. Cette approche permet de concentrer des ressources souvent limitées sur la protection des actifs et des données les plus importants. Par exemple, une organisation peut identifier les applications associées au traitement de transactions par carte bancaire et y concentrer ses efforts de sécurisation afin de se conformer aux recommandations de l’industrie des cartes de paiement (PCI DSS par exemple).

Ainsi, les experts supervisent l’ensemble des processus de sécurisation de l’entreprise et aident à analyser les résultats de tests de sécurité. Ce modèle aide les entreprises à renforcer la sécurité de leurs systèmes d’information en les mettant à l’épreuve au sein même des processus existant de développement, d’assurance qualité et d’exploitation.

Puisque trouver et corriger les vulnérabilités très tôt dans le processus de conception permet de réduire les coûts, ce modèle aide les entreprises à renforcer la sécurité de leurs systèmes d’information à moindre coût, en industrialisant les tests de sécurité au travers de l’intégralité du cycle de vie des applications.

Les logiciels HP WebInspect 8.0 et HP Assessment Management Platform 8.0 sont basés sur la même infrastructure de scanning et de reporting. Tous deux aident les entreprises à :

  • Trouver et corriger les vulnérabilités dans les applications Web 2.0 avec les fonctions d’analyse statique des applications conçues pour la plateforme Adobe® Flash platform et de suivi dynamique pour les applications JavaScript/Ajax.
  • Mettre en œuvre des scans automatiques qui ne pouvaient, jusqu’ici, être réalisés que manuellement. Ceci concerne notamment, le suivi en profondeur pour les applications Java™ Model View Control
  • Gagner du temps grâce à de nombreuses fonctions d’automatisation, permettant une configuration plus rapide des tests, et à des fonctions prêtes à l’emploi de reporting
  • La nouvelle offre HP SaaS Project Services for Application Security Center aide les entreprises à commencer rapidement l’exploitation de HP Application Security Center, à la demande.




Comment tester en « mode agile » ?

18 05 2009

Comme promis aux nombreux lecteurs m’ayant fais la demande, je vous présente cet article traitant des tests en mode agile. Il s’agit d’une vulgarisation et je tente de vous présenter les principes et points importants à prendre en compte.

SCRUM, XT programming et autres acronymes du même acabit sont légions depuis quelques années et sont très en vogue parmi les développeurs. En fait il s’agit de développer le plus rapidement possible quelques fonctionnalités et de mettre tout aussi rapidement en production (d’où le terme de sprint que nous verrons plus tard) !

Et le test me direz-vous ?

Les activités de tests sont bien entendu réduits à au maximum… mais… il faut savoir qu’il y a une méthodologie spécifique concernant les activités de tests et qui s’insère naturellement et simplement en mode agile.

En premier lieu je passe en revue les deux méthodes de développements les plus connues dans le mode agile. En effet, elles représentent la majorité des projets de ce type (nos chers développeurs les préfèrent aussi). Il s’agit du SCRUM et de l’eXtreme Programing.

Méthode SCRUM :
La définition du mode agile est en partie basée sur la remarque suivante : « … L’approche course de relais pour le développement de produits…peut être en conflit avec les objectifs de vitesse et de flexibilité maximum. A l’inverse, une approche holistique comme au rugby— quand une équipe essaie d’avancer en restant unie, en se passant le ballon de main en main— peut mieux servir les exigences de compétitivité d’aujourd’hui ». Hirotaka Takeuchi et Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, Janvier 1986.

Ainsi le SCRUM est un processus agile qui permet de produire la plus « grande valeur métier » dans la durée la plus courte. Du code est produit à chaque sprint (toutes les 2 à 4 semaines).

Le métier (les utilisateurs par exemple) définit les priorités. L’équipe de développeur s’organise elle-même pour déterminer la meilleure façon de produire les exigences (ou backlog) les plus prioritaires.

Et à chaque fin de sprint, tout le monde peut voir fonctionner le produit courant et décider soit de le livrer dans l’état, soit de continuer à l’améliorer pendant un sprint supplémentaire.

Les grands principes du SCRUM :

  • Equipe responsable, en auto-organisation
  • Avancement du produit / code par une série de « sprints » de 5 jours maximum
  • Exigences définies comme des éléments d’une liste appelée « backlog du produit »
  • Pas de prescription de pratiques d’ingénierie
  • Utilisation de règles génériques permettant de créer un environnement agile pour un projet

eXtreme programming :
En 2001, aux États-Unis, dix-sept acteurs clés du développement logiciel se sont réunies pour débattre de leurs méthodes respectives, dites méthodes agiles. Les plus connus d’entre eux étaient :

  • Ward Cunningham l’inventeur du Wiki via WikiWikiWeb
  • Kent Beck, père de l’extreme programming et cofondateur de JUnit
  • Ken Schwaber et Jeff Sutherland, fondateurs de SCRUM
  • Jim Highsmith, prônant l’ASD
  • Alistair Cockburn pour la méthode Crystal clear
  • Martin Fowler et Dave Thomas
  • Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD (Développement rapide d’applications).

Ces nombreux experts réussirent à extraire de leur méthodes respectives des critères pour définir une nouvelle façon des développer des logiciels. De cette réunion devait émerger le Manifeste Agile, considéré comme la définition du développement agile et de ses principes.

Ainsi leurs conclusions furent :

Principales causes identifiées de l’échec des projets :

  • Mauvaise compréhension du besoin : 51%
  • Estimation et planification déficiente : 48%
  • Technologies mal maîtrisées : 45%

Méthodes classiques trop lourdes :

  • Manque de réactivité
  • Excès de documentation

But : produire un logiciel de qualité en respectant les délais et le budget grâce à un ensemble de pratiques efficaces poussées à l’extrême.

Dans la pratique les choses sont bien différentes… En effet, les délais et budgets sont à peine respectés (comme dans les projets en mode classique – processus en V et autres) et la qualité est inconnue de la plupart des développeurs.

En fin de compte les problèmes concernant les tests sont les mêmes sur tout les projets. Le principal étant la non connaissance des bonnes pratiques de tests par les chefs de projets (ou scrumMaster) et les développeurs (ou CoWboyZ).

Ainsi le mode agile possède aussi quelques bonnes pratiques à mettre en œuvre et faire respecter par les ScrumMaster et autres chefs de projet. Voici celles que j’ai apprises et optimisées lors de mes missions.

Ci-dessous le processus de développement logiciel en mode agile :

image1_agile

On constate que le processus fonctionne un peu comme un sous-marin, avec des compartiments devant rester étanches, sous peine de ne plus respecter le processus…

  • Ainsi, les métiers définissent leurs besoins et exigences, ils les communiquent au chef de produit
  • Le chef de produit en fais une synthèse et en propose une priorisation au chef de projet (ou ScrumMaster)
  • Ensuite, le chef de projet les prends en compte et détermine les exigences (ou backlogs) qui seront développés par son / ses équipes « agiles ».
  • Sachant que les users métiers ne doivent parler qu’uniquement au chef de produit et que celui-ci est le seul à parler avec le chef de projet
  • Enfin, les développeurs et testeurs ne peuvent pas parler avec les users ni les chefs de produit

Ce mode de « communication en mode étanche » a été préconisé à l’époque afin d’assurer la tranquillité de l’équipe de développement et s’assurer que ceux-ci ne seraient pas dérangés. Ainsi, les créateurs du mode agile crurent assurer en partie par ce biais le respect des délais et des budgets.

Mais, les effets pervers de ce mode étanche sont :

  • Pas ou peu de cahier des charges / spécifications en entrée des développements
  • Les besoins et exigences des utilisateurs sont filtrés et surtout réinterprétés par trois personnes différentes ayant chacun des priorités et objectifs différents
  • Pas de traçabilité des exigences
  • Des effets de ralentissements ou « d’à peu près » car quand un développeur a une question sur une fonctionnalité à coder, il ne peut la poser qu’au chef de projet qui demandera au chef de produit qui demander aux utilisateurs. La réponse (si la question a bien été posée) prendra le chemin en sens inverse…
  • Les testeurs non presque pas de documentation et doivent souvent attendre la fin du  deuxième sprint pour avoir une certaine visibilité sur ce qu’il y aura à tester

Finissons cette description du processus logiciel en mode agile par la communication au sein de l’équipe agile.

  • En début de chaque sprint (tous les lundis donc car un sprint = 5 jours) il y a une réunion de démarrage qui doit aborder le planning, les outils, etc.
  • Pendant les sprints il y a une réunion quotidienne ne devant pas avoir lieu dans une salle (ceci reste un mystère pour moi j’avoue) mais plutôt dans un lieu incongru et très bruyant comme la salle à café ou équivalent. Cette réunion ne doit pas dépasser 15 minutes (avec des questions comme : les problèmes rencontrés, etc.)
  • Le reste de la communication est assurée par les « Instant Messenger » comme MSN et équivalent (même si les développeurs et testeurs sont dans le même bureau, ce qui est hallucinant à vivre je vous l’avoue !)

Synthèse des fondamentaux de l’agile :

  • Sprint et itérations très courts
  • Une équipe ne communiquant que par son scrumMaster
  • Spécifications « rédigées » pendant les sprints
  • Pas de plan de tests – scripts « one shot »

Ci-dessous le séquencement d’un projet agile :

image2_agile

Au sein d’un projet il y a plusieurs releases. Chaque release est composé de plusieurs sprint. Tous les 3 ou 4 sprints une release / package est construite par les développeurs (en 1 journée grand maximum). Puis, le package doit-être mis en production. Si vous avez lus mes articles précédents vous constaterez bien vite qu’il manque une étape importante avant la mise en production… (Roulement de tambour… suspens…), il s’agit des tests avant la mise en production. Comme :

  • Les tests de performance
  • Les tests d’exploitabilité
  • Les tests d’installations
  • Les tests de MEP à blanc, etc.

Bonnes pratiques :

  • Mettre en place une machine d’intégration continue qui assurera la « récolte » des développements, leurs sauvegardes et leurs versions
  • Prévoir, définir et mettre en œuvre les tests devant valider les packages :
  • Souvent cette étape se résume à un combat pour l’imposer auprès des chefs de projet qui trouve que les tests ne font pas partie du mode agile et ralentissent le processus. Ces mêmes chefs de projet qui subitement changent d’avis après des mises en production sans tests préalable… C’est ce que l’on appel l’expérience par l’échec.

image3_agile
Détaillons les activités de tests dans le mode agile en prenant un exemple concret :

Dans le schéma ci-dessus j’ai modélisé une release comportant uniquement deux sprints, une étape de packaging et la mise en production (MEP).

Itération 1 – Planning du sprint 1 (ou S1) :

  • Lundi 2 février au matin : réunion de démarrage (1 heure maximum – A). Le scrumMaster explique aux 3 développeurs et au testeur unique les backlogs (B) devant être développés et testés
  • Lundi 2 au vendredi 6 février matin les développeurs on les tâches suivantes :
  • Prise de connaissance des backlogs fourni par le scrumMaster
  • Développements (codage en Java – C) des backlogs (et des classes de tests bien entendu) :
  • + Tests unitaires (D) en utilisant Junit et Javadoc au sein du framework Eclipse
  • Chaque les développeurs « commit » leurs bouts de code. Ce code est pris en charge dans le processus d’intégration continue (E)
  • Lundi 2 au vendredi 6 février matin le testeur a les tâches suivantes :
  • Prise de connaissance des backlogs
  • Lecture des rapports de tests générés par Junit
  • Création des scripts de tests (sous Selenium – F)
  • Vendredi 6 février après-midi :
  • Le scrumMaster décide lors de la réunion matinale quotidienne de mettre fin au sprint 1 (S1) ce vendredi en fin de journée car il estime que les objectifs ont été atteints. Il envoi un mail pour en prévenir le chef de produit.

Planning du sprint 2 (S2) :

  • Lundi 9 au 13 février matin : réunion de démarrage (1 heure maximum). Le scrumMaster explique aux 3 développeurs et au testeur unique les backlogs devant être développés et testés
  • Lundi 9 au 13 février matin les développeurs on les tâches suivantes :
  • Prise de connaissance des backlogs fourni par le scrumMaster
    Développements (codage en Java) des backlogs (et des classes de tests bien entendu) :
    + Tests unitaires en utilisant Junit et Javadoc au sein du framework Eclipse
    Chaque les développeurs « commit » leurs bouts de code. Ce code est pris en charge dans le processus d’intégration continue
  • Lundi 9 au vendredi 13 février matin le testeur a les tâches suivantes :
    Prise de connaissance des backlogs S2
    Lecture des rapports de tests générés par Junit du S2
    Création des scripts de tests (sous Selenium) pour le S2
    + Le testeur doit aussi faire en parallèle (dès le lundi après la réunion) :
    Lancement et surveillance des scripts du S1 (H)
    Remontée des anomalies sur les backlog du S1 au scrumMaster (uniquement à lui – qui est juge et partie sur la décision de corriger ou pas les anomalies remontées par le testeur – G)
  • Vendredi 13 février après-midi :
    Le scrumMaster décide lors de la réunion matinale quotidienne de mettre fin au sprint 2 (S2) ce vendredi en fin de journée car il estime que les objectifs ont été atteints. Il envoi un mail pour en prévenir le chef de produit et indique qu’une mise en production est possible sans problème
    La MEP est effectué par un des développeurs. Juste avant de partir en week-end il lance l’installation en étant sur à 100% que tout se déroulera bien (I)

Fin de l’itération 1

J

Voici donc le fonctionnement typique d’une équipe agile classique. Suivant vos expériences, vous vous apercevrez qu’il y a de nombreuses erreurs de jugement et de très importants manques aux niveaux des tests !

Je vais lister ci-dessous les bonnes pratiques pouvant être mises en œuvre dans un projet agile. Sachant que ces bonnes pratiques devront être présentées et défendues auprès du scrumMaster, par le testeur.

L’intervention des bonnes pratiques est signalées par une lettre dans le planning ci-dessus et expliquées en détails ci-dessous :

image4_agile

Lien vers l’article traitant des tests unitaires.





How to make unit test?

18 05 2009

The unit test :

Definition:

“Test Unit (TU) (development test): A unit test is a test conducted by the developer in development environment; it is intended to demonstrate a unit complies with the criteria defined in the technical specifications.”

In the case of a procedural language unit is « the process », and in the case of an object-oriented unit is represented by « The Class. »

Unit testing is testing the first white box-type to be charged by profile type developers.

In the case of this kind of test the important question is « What is the quality of the units developed and how to measure it?

Thus, it is for the developer to test a module, independently of the rest of the program in order to ensure that it meets the requirements (functional / technical) and it works correctly. This audit is currently an audit of code coverage, which is to ensure that the test leads to perform all (or a portion) of the instructions in the code to test.

Thus, it should be understood that the unit must conduct (or the piece of code):

  • Check the functions and roles of the Unity
  • Test the boundaries of the unit (bounds: zero, one, complete. Search an empty collection, for example)

This results in a simple way by creating a test class per class developed.

Example of basic unit tests and represented by a class of test:

  1. Invoke the method with the values passed as parameters
  2. Observe the results
  3. Check if the results are those expected

Thus we must select values for which we can determine the outcome.

As we see it may take time to perform these tests manually. Similarly, if classes are complex and that we must carry out regression tests…

To help the developer tools exist and JUnit is the most effective (see details in the section on tools).

Examples of other types of unit tests:

  • Audit code: verification step of lines of code against a standard development
  • Bound checking tool to check any entries in the memory areas
  • Documentation: reading source code automatically generating descriptions of the code
  • Memory leak detectors: these tools tests memory allocation applications
  • Static code (path) analyzer: it is identifying paths / code structure as measured McCabe, etc.

Unit testing tools:

Tools integration:

  • MAVEN: free software tool for the management and automation of production of Java software projects. It provided a way to synchronize independent projects: publication Standardized information vending module jar. In basic version, Maven can dynamically download material on storage software known. It offers the transparent synchronization of modules required.
  • ANT : idem que MAVEN
  • Continuum
  • CVS Subversion
  • JIRA

The testing Framework:

The best approach to undertake unit testing is to establish a « prepared environment » (or Framework) that is dedicated. In the case of development of Java type, the combination is the perfect synergy of tools below:

  • Java development environment integrated with Eclipse in it:
  • unit testing tools: JUnit (Tools written by the creator of the programming Xtrem Kent Beck), it allows to test the development of Java type
  • Generating doc. : JavadocC# / .Net : NUnit
  • C++ : CPPUnit / CUnit
  • Fortran : fUnit
  • Delphi : DUnit

The three basic concepts of JUnit are:

  1. Verdict: Each test can go GREEN (OK or pass) or red (fail or NOK)
  2. Test case: determining if a method produces good results for a given set of values passed as parameters:
    • Represented by a method in a class test
    • There have as many methods as you want in a class of tests
    • There is often a test class for each class to test (one to one)
  3. Test suite: it contains a set of test cases for one class

The analytical coverage tests:

  • Cobertura. It can produce:
    • The number of classes per package
    • The percentage of lines tested
    • The percentage of tested expressions
    • The list of components with the test unit is in error (list of anomalies by component / access services concerned)
  • EMMA
  • Clover

Tools Control code:

Checkstyle: This control ensures a well-defined level of quality of source code.

The reporting tools

Weekly reporting is generated and provided through the tool MAVEN.

Reports to generate 1: Unit Testing in error

This report presents a summary of all the tests and highlights the following:

  • Number of tests
  • Number of errors
  • Percentage of success

Reports to generate 2: Coverage of unit tests

Tools defects:

Each anomaly must be met up through a management tool defects. Thus, the anomalies are included in the tool as tests.

The analysis should lead to:

  • Changing the unit test to incorporate a change in the code. The change was made to replay developer testing
  • The amendment of the Code, if a regression is found. The corrected source code is up for re-replay testing and closure of the defect if the test is validated

Some tools:

  • Mantis
  • BugZilla
  • The module of Quality Center Defects (ed. HP Mercury)

Reminder of good practice in unit tests:

  • Use a framework absolutely
  • Interface with the framework tools
  • Write tests before code
  • A class = test
  • To test the classes in the same package (same directory) that the classes related
  • Code unit tests must change with the application and must be maintained
  • The name of the classes of tests must necessarily include the word TEST (to distinguish them easily and Junit 3 and found her classes)
  • As for automated functional testing make sure to put the system in the same condition as before the tests (this « rehabilitation » may be part of the actions of your Selenium test scripts for example)
  • How to reduce test time:
  • Isolate the unit tests identified as greedy time (DB access, competition …) and run less frequently than every compilation, for example: before each filing of source code in the common code base
  • Do the unit tests on the assembly that has been modified and not the entire

To write this article I helped my experiences but also the return of developer and sites such as (whom I thank for their very informative articles):

I advise you to report for more details on the subject.





Comment mettre en oeuvre des tests unitaires ?

18 05 2009

Définition :

« Test Unitaire (TU) (ou test de développement) : un test unitaire est un test mené par le développeur en environnement de développement, il a pour but de démontrer qu’une unité respecte bien les critères définis dans les spécifications techniques ».

Dans le cas d’un langage procédural l’unité est « la procédure », et dans le cas d’un contexte orienté objet l’unité est représentée par « La classe ».

Les tests unitaires sont les premiers tests de type boite blanche devant être pratiqués par des profils de type développeurs.

Dans le cas de ce type de tests la question importante est « Quel est la qualité des unités développés et comment le mesurer ? ».

Ainsi, il s’agit pour le développeur de tester un module, indépendamment du reste du programme, ceci afin de s’assurer qu’il répond aux spécifications (fonctionnelles / techniques) et qu’il fonctionne correctement. Cette vérification s’accompagne couramment d’une vérification de la couverture de code, qui consiste à s’assurer que le test conduit à exécuter l’ensemble (ou une fraction déterminée) des instructions présentes dans le code à tester. ».

Ainsi, il faut comprendre ce que l’unité doit effectuer (ou la parcelle de code) :

  • Vérifier les tâches et rôles de l’unité
  • Tester les frontières de l’unité (bornes : zéro, un, complet. Chercher une collection vide par exemple)

Cela se traduit de manière simple par la création d’une classe de test par classe développée.

Exemple de tests unitaires de base et représenté par une classe de test :

  1. Invoquer la méthode avec des valeurs passées en paramètres
  2. Observer les résultats
  3. Vérifier si les résultats sont ceux attendus

Ainsi il faut sélectionner des valeurs pour lesquelles on peut déterminer les résultats attendus.

Comme on le voit cela peut prendre du temps d’effectuer ces tests de manière manuelle. De même si les classes sont complexes et que l’on doit procéder à tests de non régressions…

Pour aider le développeur des outils existent et Junit est le plus efficace (voir détails dans le paragraphe sur les outils).

Exemples d’autres types de tests unitaires :

  • Audit de code : vérification pas à pas des lignes de codes vis-à-vis d’un standard de développement
  • Bound checking : Outil permettant de vérifier d’éventuelles écritures dans les zones mémoires
  • Documentation : lecture de code source générant automatiquement les descriptions du code
  • Memory leak detectors : ces outils tests l’allocation en mémoire des applications
  • Static code (path) analyzer : il s’agit d’identifier les chemins / structure de code selon les mesures McCabe, etc.


Outillages des tests unitaires :

Outils d’intégration continue :

  • MAVEN : outil logiciel libre pour la gestion et l’automatisation de production des projets logiciels Java. Il fourni un moyen de synchroniser des projets indépendants : publication standardisée d’information, distribution automatique de modules jar. En version de base, MAVEN peut dynamiquement télécharger du matériel sur des entrepôts logiciels connus. Il propose ainsi la synchronisation transparente des modules nécessaires.
  • ANT : idem que MAVEN
  • Continuum
  • CVS Subversion
  • JIRA

Les Framework de tests :

La démarche optimale pour entreprendre les tests unitaires est de mettre en place un « environnement préparé » (ou Framework) qui soit dédié. Dans le cas de développement de type Java, la combinaison parfaite est la synergie des outils ci-dessous :

  • Java : Environnement de développement intégré : Eclipse avec en son sein :
    • Outils de tests unitaires : Junit (Outils écris par le créateur de l’Xtrem programming Kent Beck), il permet de tester les développements de type Java
    • Génération de doc. : Javadoc
  • C# / .Net : NUnit
  • C++ : CPPUnit / CUnit
  • Fortran : fUnit
  • Delphi : DUnit

Les trois concepts de bases de Junit sont :

  1. Verdict : chaque test peut passer en VERT (pass ou OK) ou en ROUGE (fail ou NOK)
  2. Cas de test : détermine si une méthode produit les bons résultats pour un ensemble donné de valeurs passées en paramètres :
    1. Représenté par une méthode dans une classe de test
    2. Il y avoir autant de méthodes que voulu dans une classe de tests
    3. Il existe souvent une class de test correspondant à chaque class à tester (one to one)
  3. Tests suite : elle contient un ensemble de cas de test pour une classe

Les outils d’analyse de couverture des tests :

· Cobertura. Il peut produire :

o Le nombre de classes par paquetage

o Le pourcentage de lignes testées

o Le pourcentage d’expressions testées

o La liste des composants dont le test unitaire est en erreur (liste des anomalies par composant / services d’accès concernés)

· EMMA

· Clover

Outils de contrôle de code :

Checkstyle : Ce contrôle permet d’assurer un niveau bien défini de qualité de code source.

Les outils de reporting

Un reporting hebdomadaire est prévu et généré au travers de l’outil MAVEN.

Rapports à générer 1 : Tests unitaires en erreur

Ce rapport présente une synthèse de l’ensemble des tests et fait ressortir les éléments suivants :

Nombre de tests effectués

Nombres d’erreurs

Pourcentage de réussite

Rapports à générer 2 : Couverture des tests unitaires :

Outils de gestion des anomalies

Chaque anomalie rencontrée doit être remonté au travers d’un outil de gestion des anomalies. Ainsi, les anomalies sont intégrées dans l’outil au fur et à mesure des tests. L’analyse doit conduire à :

· La modification du test unitaire afin d’intégrer une évolution du code. La modification est réalisée développeur pour rejeu des tests

· La modification du code, si une régression est constatée. Le code source corrigé est re-livré pour rejeu des tests et clôture de l’anomalie si le test est validé

Quelques outils :

  • Mantis
  • BugZilla
  • Le module Defects de Quality Center (éditeur HP Mercury)

Rappel des bonnes pratiques dans les tests unitaires :

  • Utiliser absolument un framework
  • Interfacer le framework avec les outils
  • Ecrire les tests avant le code
  • Une classe = un test
  • Mettre les classes de tests dans le même package (et même répertoire) que les classes s’y rapportant
  • Le code des tests unitaires doit évoluer avec l’application et doit donc être maintenu
  • Le nom des classes de tests doivent comporter obligatoirement le mot TEST (pour les différencier facilement et Junit 3 retrouve ses classes ainsi)
  • Comme pour les tests fonctionnels automatisés pensez bien à remettre le système dans le même état que celui d’avant les tests (cette « remise en état » peut faire partie des actions de vos scripts de tests Selenium par exemple)
  • Comment réduire les temps de test :
    • Isoler les tests unitaires identifiés comme gourmand en temps (accès DB, concurrence…) et les exécuter moins souvent qu’à chaque compilation, exemple : avant chaque archivage du code source dans la base de code commune
    • N’exécuter que les tests unitaires concernant l’assemblage qui a été modifié et non pas l’intégralité

Pour rédiger cet article je me suis aidé de mes expériences mais aussi du retour de développeur et de certains sites comme (que je remercie pour leurs articles fort instructifs) :

Je vous conseil de vous y rapporter pour plus de détails sur le sujet.





Que sont les tests d’exploitabilité ?

5 04 2009

Définition des tests d’exploitabilité :
Dans une entreprise (E1), l’entité responsable des applications et SI est à 99,8% nommée « la production ». Sa responsabilité concerne le fait de s’assurer et surveiller que ces applications sont en ligne (pour des sites Web par exemple), soient accessible par les clients et que les commandes effectués par ces mêmes clients puissent arriver et être traitées par les gens de l’entreprise E1.
La plupart du temps les « gens d’la prod’ » sont totalement invisible au commun des mortels que nous sommes. Ils sont présents le jour et la nuit et restent plutôt invisible.
Si un jour vous les croisez vous pourrez les remercier pour leur travail car il n’est pas si facile et vraiment très peu valorisé dans la plupart des sociétés.

« Mais quel rapport avec les tests tonton MAT ? »

Et bien, depuis quelques années déjà, (a long long years ago – façon début de légende), « les gens d’la prod’ » ne sont plus seul ! Un service, se situant juste avant la production, est souvent en charge de TESTER les applications avant de les confier à la production. Ce service est souvent nommé « Exploitation, pré-exploitation ou pré-production » (cela dépend de l’entreprise).
Ce service est donc en charge de vérifier certains aspects des applications qui seront ensuite installées par le service « production ».
Pour comprendre les tests devant être effectués par l’exploitation il faut tenter de comprendre un peu plus le travail journalier des « gens d’la prod’ ».

La « production » est donc focalisée sur la disponibilité et la qualité des services qu’elle doit délivrer, tout en garantissant la capacité à prendre en compte les évolutions du SI. Elle est la garante de la « mise en production » des modules faisant partie du SI de l’entreprise, ainsi que de la surveillance de ces modules. Ceci au niveau, performance, disponibilité, sauvegarde, etc.

Il existe des indicateurs pour mesurer tous ces points à vérifier et surveiller. Ils sont mesurés par rapport à des métriques claires et cohérentes en ligne avec les besoins métier. La plupart du temps ces indicateurs se trouvent réunis dans un document nommé SLA (Service lLevel Agreement) ou OLA (Operation Level Agreement). Il existe des outils dédiés pour mesurer la performance de ces indicateurs, mais j’u reviendrai plus tard.

Pour surveiller ces indicateurs, la production s’appuie donc sur des processus clairement définis et adoptés (espérons le du moins) dont l’objectif est le même pour remplir ses missions. Les missions principales sont :
Maintien de la disponibilité des services

  • Piloter
  • Exploiter et administrer

Maintien de l’intégrité de l’infrastructure

  • Maintenir l’infrastructure
  • Intégrer en production
  • Supporter

Qualité et cohérence des processus

  • Manager
  • Mesurer et améliorer
  • Capitaliser

Assurer la mise en production de nouvelles applications
Ainsi, la préoccupation permanente de la production est la recherche de l’excellence opérationnelle. Pour l’obtenir, elle applique les quatre règles visant à garantir l’intégrité de son périmètre :

  • Tous les outils standards (ou défini comme tel) et uniquement les outils standards sont implémentés et utilisés
  • Tous les projets sont initialisés via un processus formel dans lequel la production intervient pour l’intégration en production
  • Seuls les systèmes testés techniquement sont sous la responsabilité de la Production
  • Faire face aux risques majeurs. Et pour cela établir un Plan de Retour à l’Activité (PRA)

our que ces quatre règles puissent être vraie il faut que le service « exploitation » tests plusieurs points avant que les applications ne passent dans le service « production ». La recette d’exploitation a donc pour rôle, en tant que partie de la recette technique, de vérifier et homologuer l’exploitabilité de la solution à mettre en œuvre et sa conformité aux normes d’exploitation instaurées par la production.

Ci-dessous je développe les différents types de tests d’exploitation. Il en existe surement d’autres ou bien certain de ces tests sont déjà pris en compte par la production. Quoiqu’il en soit ces tests doivent être réalisés. Et ceci, par le service que vous voulez !

Le périmètre des tests d’exploitation concerne les :

Tests de conformité aux normes d’exploitation :

  • Vérification de la conformité aux normes et standards d’exploitation des procédures et documentations
  • Vérification de la prise en compte des consignes d’exploitation et de support (gestion des incidents et gestion des problèmes)

Test du plan de production / plan de bascules :

  • Validation des documentations des plans de production
  • Recette du plan de production
  • Vérification des procédures de mise en production (change management)
  • Validation de l’ordonnancement

Tests des procédures de supervision :

  • Vérification de la conformité des messages d’erreur aux normes et standards
  • Tests de détection et de gestion des anomalies
  • Validation et diffusion des documentations applicatives et systèmes

Tests de robustesse :

  • Tests de charge
  • Crash test
  • Reprise de traitement
  • Mode dégradé

Tests des servitudes de production :

  • Recette des sauvegardes / restauration et procédures
  • Recette des purges, historisation et archivage ainsi que les procédures

Plan de Capacité :

  • Vérification de la mise à jour du plan de capacité
  • Vérification du trafic réseau et des classes de services

Tests du PRA (le plus sympa à tester)

Ci-dessous je détaille plus avant chaque test. Quand je parle de plan de tests je veux signifier que les tests sont tous rédigés et exécutés dans un référentiel de tests (TESTLINK, QUALITY CENTER, etc.). Si cela n’est pas le cas « c’est le mal ! ». Plaisanterie mise à part, TOUS les types de tests doivent être basés dans un référentiel de tests. Au final, tous ces types de tests représentent les exigences devant être pris en compte et à ce titre devenir des exigences de tests dans le référentiel de tests.
Bien entendu une stratégie des tests d’exploitabilité doit être définie (vous n’y échapperez pas bande de canaille !).
Mais voyez plutôt mes autres articles sur le sujet.

Tests de conformité aux normes d’exploitation :
Les normes d’exploitation regroupent les règles et conventions qui régissent :

Les normes d’exploitation regroupent les règles et conventions qui régissent :

  • L’installation d’une application en tant qu’ensemble de programmes permettant d’assurer une tâche ou une fonction particulière
  • Le nommage, la définition et l’installation d’un environnement en tant qu’instance d’une application avec ses différents composants (logiciels, interfaces, traitements, bases de données, etc.) s’inscrivant dans un contexte d’utilisation en relation avec la gestion de cette application : production, développement, intégration, recette, etc.
  • Le nommage et la définition d’un traitement ou d’un job (ou batch) en tant qu’opération automatisée (script, programme, etc.)
  • Les normes d’écriture des scripts (shell) lanceurs ou applicatifs
  • Le nommage et la définition d’une chaîne d’ordonnancement regroupant les traitements dans un ensemble cohérent et interdépendant (Crontable ou ordonnanceurs d’un éditeur)
  • La définition des interfaces en tant que flux entrant ou sortant d’une application
  • Les normes et définitions des sas de transfert en tant que lieu d’échange de fichiers inter-applications

Le plan de tests d’exploitabilité listera donc la conformité des points suivants :

  • Recette du dossier d’exploitation :
    • Schéma d’architecture technique de l’application
    • Nommage et description de l’arborescence applicative (binaires, données, logs, …)
    • Description et nommage des composants de l’application (serveurs, bases de données, logiciels, …)
    • Nommage des tablespaces, schémas et objets Oracle des SGBD de l’application
    • Identification et nommage des users applicatifs
    • Description des flux de l’application
    • Consignes de reprise
    • Description du fonctionnement en mode dégradé
    • Description des répertoires à purger, historiser et archiver (consignes, fréquences, rétention, …)
    • SLA de l’application

Recette du dossier d’ordonnancement :

  • Schémas des chaînes d’ordonnancement applicatifs
  • Description des chaînes job par job (batch ou chaine de batch)
  • Calendriers de planification des chaînes
  • Description des interfaces
  • Liste des codes retour
  • Description des cas d’erreur
  • Procédures de reprises
  • Gestion des logs

Recette du dossier de supervision :

  • Description des processus sensibles de l’application
  • Description et seuils de volumétrie des  tablespaces
  • Description et seuils de volumétrie des filesystems à surveiller
  • Consignes d’exploitation sur anomalies

Recette du dossier de sauvegarde :

  • Noms et description des polices de sauvegarde (arborescence, type, fréquence,  …)
  • Noms et descriptions des chaînes de sauvegardes (type, planning, rétention,…)
  • Schémas des chaînes de sauvegarde

Test du plan de production :
Le plan de production décrit et prépare le déploiement de l’application devant être installée dans le SI de E1. Il comprendra les composants applicatifs packagés sous une forme respectant les normes E1 et permettant un déploiement tel quel, quel que soit l’environnement concerné. La documentation fournie en phase de test d’exploitabilité sera complétée des éléments suivants :

  • Packages fonctionnels
    Check-lists de déploiement
    Dossiers d’installation
    Procédures de mise en œuvre en production
    Procédures et plannings de changements en production (formations, mise à jours contrats maintenance, …)

L’installation des composants cibles applicatif ou techniques de l’application sera réalisée conformément aux guides d’installation applicatifs fourni et / ou aux spécifications d’architecture.

Le plan de test du plan de production comprendra :

  • Validation des documentations de déploiement
  • Recette des check-lists de déploiement
  • Recette de la documentation d’installation
  • Tests des procédures de mise en œuvre en production
  • Validation des ordonnancements batchs (fenêtres de déclenchement, périodicité, temps de traitement, conformité de la gestion des codes erreurs, …)
  • Recette fonctionnelle de l’environnement

Tests des procédures de supervision :
Ils consistent à simuler des cas d’erreur construits selon les composants à superviser identifiés dans la documentation d’exploitation.
Ces tests ont pour but de vérifier la validité de la détection des anomalies et la conformité des messages d’erreur ainsi que la bonne application des consignes de gestion de ces anomalies :

  • Vérification de la conformité des messages d’erreur aux normes et standards
  • Tests de détection et de gestion des anomalies
  • Validation des consignes
  • Validation et diffusion des documentations applicatives et systèmes

Tests de robustesse :
En complément des tests de performance qui valident la conformité de l’application aux exigences de temps de réponse et d’optimisation système, les tests de robustesse doivent permettre de valider la conformité du comportement en charge de l’application aux exigences d’exploitation d’E1.

Les cas de tests permettront la restitution de l’ensemble des attendus recensés :

Tests de charge en mode nominal (utilisation CPU, I/O, volumétrie, …)

  • Reprise de traitement batch sur incident de production
  • Crash test (comportement et stabilité sur arrêt d’un serveur)
  • Temps de bascule sur instance Oracle passive
  • Performances en mode dégradé (max 50% en clustering sur perte d’1 nœud)

Tests des servitudes de production :
Les tests des servitudes de production tests le fonctionnement des sauvegardes/restauration et leur conformité avec les procédures et modalités décrites dans la documentation afférente.

Les cas de tests identifiés restitueront la couverture des exigences suivantes (informations figurants pour exemple – à adapter selon le contexte / projet / SLA de E1) :

  • Sauvegarde des données (schémas Oracle, documents GED, traces, etc.)
    Sauvegarde application (exécutables, fichiers de configuration, briques techniques, etc.)
    Sauvegarde système (création d’images du système d’exploitation vierge d’application, etc.)
    Sauvegarde Oracle à chaud en mode begin backup
    Sauvegardes SAN durée max 15 mm
    Durée de restauration données + application 2h max
    Durée de restauration système complet 8h max
    Validation de l‘intégrité des éléments restaurés

Tests de PRA :
Un Plan de Reprise d’Activité est mis en œuvre après un sinistre majeur (perte de salle machine, incendie, attentats, inondations et autres catastrophe naturelle ou d’origine humaine). Il doit permettre un retour à l’activité dans des délais définis. Souvent, ce retour ce fait en mode dégradé, de manière temporaire jusqu’au retour en mode normal (arrivée de nouveaux serveurs, réplication du SI effective, etc.).
Dans le PRA figure donc le RACI (le qui fais quoi, comment et quand ?) ainsi que les actions devant être mises en œuvres ainsi que leurs ordonnancement clairement définis, approuvés par tous les acteurs du PRA avec les procédures réellement appropriées par tous.

Certes, il n’est pas facile de tester l’intégralité d’un PRA mais néanmoins certaines situations doivent être répétées pour qu’il n’y ai aucune surprise pour aucun des acteurs dans les moments de crise – le PRA est là pour cela, sinon il ne sert à rien. Pour exemple, au moment de l’incendie (et inondation dans la foulée) du Crédit Lyonnais à Paris il y a quelques années, des pertes de données importantes ont été subies car ce type de risques / sinistres majeurs n’avait pas été assez pris en compte (entre autre).

Les cas de tests devront être choisis avec soins en ayant à l’esprit le ratio : risques / coûts / occurrence.

Par expérience, exécuter les tests de PRA quand tous les acteurs sont averties et sur le pont ne sert strictement à rien ! Pour cela, seul le DSI, le responsable de la production et un observateur externe doivent être au courant. Le résultat des tests sera ainsi très représentatifs de l’état de préparation et d’appropriation du PRA par les acteurs impliqués (et au final très amusant à vivre pour un consultant externe ;-).
Pour finir, il faut savoir que c’est souvent le service en charge de l’exploitation qui est en charge de développer et administrer les batchs, chaine de batch et autres ordonnanceurs. Ainsi, ils leurs incombent de développer et tester ces shells. Mais aussi d’administrer certaines plateformes et environnements. Cela dépend surtout de l’organisation de l’entreprise (E1).
Par conséquent, des tests spécifiques sont nécessaires pour vérifier et valider ces activités :
Tests de batch (des jobs et des jobstream) :

  • Tests unitaires – lancement, vérification du traitement désiré, vérification des fichiers log, traces, etc.
  • Tests d’intégration dans les plateformes et environnements

Tests de l’ordonnancement des batchs :

  • Tests unitaires
  • Tests d’intégration dans les plateformes et environnements

Tests des plateformes et environnements :

  • Installations des outils nécessaires
  • Création et paramétrages
Logique exploitation

Logique exploitation





Stratégie de tests type

9 02 2009
Je suis en train de mettre sur pieds une série d’article avec des présentations associées afin de vous exposer et expliquer les principaux documents nécessaires à un bon projet de test.
Ci-dessous la présentation de la stratégie de tests type qui a été éprouvée et validée par de nombreux clients et moi-même. Très prochainement je mettrai en ligne les explications.




Say Uncle … how to script with an automated testing tools and also if you could give me some good practices pleaaaaaase?

5 02 2009

Hum … and you do not want to 100 dollars and a chocolate? In short, I feel you are impatient  when listening so…

I will try to explain how to automate the functional test. I will talk about QuickTest Pro (QTP) and other selenium. Robots used for functional testing, test scenarios and test users.

There are two ways to script in QTP, it is good … and good!
Let me explain, as you might think that I do make a quick and sterile wink sketch of the “inconnu” (to our English friends: group of French comic of 90 years).

But before reviewing the ways of scripting ask what we can serve these famous robots that could be the miracle solution to testing (or not …).

Automata theory tests:
On a website (for example) QTP records your actions (recording of mouse movement, mouse clicks, etc.). And plays and replay at will. You can execute an infinite number of scenarios to test all the evening and the morning after your coffee in peace consult performance reports.
This definition is an urban myth spread by the publishers a few years ago when the automated tests were not known to clients. Since then and until now, unfortunately, it is always the thought that most customers…

Other important principles of automated tests:

  • Automatic test function by recognition of GUI objects (buttons, dropdowns, etc.). It stores in a directory called sometimes « repository »
  • During registration, they capture the interactions carried out on items needed during the course of the test. It generates a VB script (for QTP)
  • During implementation, they replay the test from the script

Automatic testing in real life:
The only true part in the theory definition is « QTP records your actions and will play it!
The rest is only possible with very little customer with a significant level of maturity in the automation of tests. In short, there are two ways to script:

The scripting for recording and reworking:
– The tester has the GUI and script directly
– It runs the script identifies and corrects errors
– Once the script is complete it must be validated by a tester and make a cross-checking (very important to finalize the scripts)

Scripting mode programming descriptive and reworking:
– The tester has no GUI and must work from technical and functional specifications. But this is very rare among customers. Furthermore this means that the specifications are complete, validated and stable… (it is good to laugh sometimes)
– It runs the script identifies and corrects errors
– Cross-checking

Important points to consider:
Principle: We automate the testing for application on a MATURE and STABLE application! Otherwise, the loss of time and masturbate to Mammoth (sorry but this is the central idea)!

– Principle: 100% of manual tests are not automatable:

  • You should know prioritize, make smart choices, use of the law of Paretto (80 / 20)
  • Explore the benefits of automation, etc.

– Principle: a feasibility study to determine the value of automated tests and technical feasibility (see another article in this subject)
– Return on investment (ROI): the automated test campaigns are profitable from only three or four iterations of automatic test campaign (from a curve ROI over three years)
– Creating scripts:

  • the burden of creating scripts is more important than the creation of manual tests
  • The difficulty is not in the capture of the script but in the choice of criteria and means of control of outcome
  • there must be synchronization points or between two actions to avoid times out on the occurrence of outcome
  • Good practice for a single scenario (better robustness of the scenario = recover under the same conditions as when you save the script):

– Preparation and application environments
– Generation of tests data
– Testing the application
– Cleaning and application environments
– Test data:

  • think about generating tests data by the automate before the execution scenarios

– Execution of scripts: load auto run is less important than manual execution
– Maintenance script: good methodology and good practices are to be applied before the start of automation to minimize the burden of maintenance scripts (standards for the organization, naming, version management scripts, etc.).
– Maintenance of scripts: it is necessary to maintain competence of automation to make the adaptations and changes in scripts if developments in the application

I finish by asking you to ALWAYS coupler and where possible automate your repository (tests management tool) with your test! This will:
– Store the description of scenarios to automate
– Store the QTP scripts in QC and associated repository
– Planning for the implementation of automated test campaigns
– Store the results of test campaigns





Say uncle… What these famous criteria are for stop the tests?

5 02 2009

It is a question often addressed in training for testing, sometimes asked by customers and never discussed by the teams of testers in the projects! Strange isn’t it?
Shutdown criteria tests are certainly not to be confused with the question « Did we tested enough? Because this is another issue concerning the coverage of tests and their completeness (among others).

Establishing criteria for tests to stop ISTQB
« Criterion release: all generic and specific conditions agreed with the managers, in order to complete a formal process. The objective of an exit test is to prevent a task is considered completed when there are still parts of this task were not completed. The exit criteria are used in the test to make reports and to schedule the shutdown of the test. [After Gilb and Graham] ».

While this definition is unclear, and that’s why I try to list the criteria the most common:
Shutdown criteria common to all types of tests:

  • All scenarios were performed (performance, functional, etc.).
  • All records, files and test cases were performed successfully
  • All critical defects have been resolved and Non-Regressions Testing (NRT) place
  • Your client to sign the minutes of revenue, the record presented and you have to keep your business
  • After 252 deliveries integrator is unable to correct and the customer decides to stop the project
  • The platforms, environments, networks, etc. are no longer available
  • Attainment of the maximum rate anomaly discovered during the (definition and achievement of a previously defined threshold). This type of test is often implemented at customers with a high level of maturity of the testing activities or imposing contractual constraints very strong.

This can also be divided by functional area. Example:

  • Stop if tests detect more than 50 major anomalies
  • Exhaustion of the resources of tests:
  • End Budget
  • Human Resources Department
  • End of time / load
  • True physical exhaustion of resources
  • The SNA receivability / testability / Pre-conditions are blocked or in NOK
  • Criteria specific to certain types of test:
  • Techniques:
  • All connectors and « jobs » (this means: jobs, jobstreams and batchs) plans have been initiated and run

Readers, if you know of another I suggest you contact us to make suggestions to the community of testers. Thank you.





Say Uncle … how to do a feasibility study prior to automate my tests?

5 02 2009

Principle: a feasibility study to determine the value of automating tests and technical feasibility. Below the summary type of a study, with some guidance to help you complete this document.
1 – First of all we must validate the technical aspects of automation: ensuring that the controller is suitable for a technical point of view to the automation of the application (on a sample of the batch scripts to automate)

  • Using documents prerequisite automata

2 – Speak the GO / NOGO

3 – Make Prototyping:
– Identify scenarios representative scenarios using existing manuals:

  • Scenario Complexity Simple
  • Scenario complexity « Medium »
  • Scenario complexity « Complex »

– Setting up scenarios and Quality Center /TESTLINK / Salome QuickTest Pro / SELENIUM:

  • Automation scenarios (eg selection criteria scenarios):
  • Scope: to automate functions stable (test of non-regression tests and no automatic changes)
  • Frequency: automate testing of functions to be tested regularly
  • Criticality: automate critical functions
  • Estimate the duration of automation for each scenario
  • Estimate the manual execution scenarios (to compare the charges)
  • Estimate the cost of maintenance scenarios there is a version

– Establish the beginnings of ROI:
– Identify « Best Practices » to implement

  • Library functions of the application, VB reusable functions, object management, etc..
  • Refer to the article on how to automate and good practices

– Identify the method for managing data sets
– Make recommendations on the management of versions of the scripts.

Below a small example of a feasibility report. This document covers:
Study Objectives
Client_xxx and your_company we agreed to conduct a feasibility study to determine if an automated test campaigns is possible.
This could yield savings in time result. Reusability as well as by third parties other than the teams your_company.

The objective of this study therefore is:
– What are the various modules / parts automatable?
– With what resources (software, tools) to automate these tests?
– The gains are significant?

  • How did we do?

A first choice initially focused on the controller (QuickTest Pro / SELENIUM) in view of the constraints and needs Client_xxx.
Then, from the scenarios in (Quality Center / TESTLINK / Salome)  we selected a few tests as significant.
Then we « Recorded and scripted » using the controller.
To illustrate more clearly the possible explanations: the video below shows an example of test automation application for AAA, with the automatic yyyy (name of the feature).
The software automatically tests:

  • Step 1
  • Step n

Attach the video of the action of the automaton (the tools available on the Internet and free).
It is important to take a concrete example or the impact on the customer will be weakened and less percussive.

  • Results of the study

The feasibility study has shown that:
– Most applications are compatible with the automation tool xxx. This compatibility has been verified through the document « ddd », provided in the appendix.
– A lot of the scenarios are automatable by Selenium:
The ‘mmm1 « , which is to verify the proper functioning of xxx
The ‘mmm2
Parts not automatable affect trade flows between different modules:
Batch
Exchange (the problem of detecting objects by xxx), etc.





Preview: new versions of Quality Center and QuickTest Pro V 10.00!

5 02 2009

I attended the presentations of new versions of Quality Center (QC) and QuickTest Pro (QTP) in the version 10.00. This HP in Issy les Moulineaux (Near to Paris – France) a rainy morning. And so, in the TGV (a very fast railway for the English) brings me back, I type this article to share with you the information provided by HP in their basement …
The celebration program was:

  • New QC 10.00
  • New BPT 10.00
  • New QTP 10.00
  • Method of pricing (on the licensing policy – a subject not treated here)
  • Demos

(Does the use of figures 10.00 warns that there will be many patch and it is expected to version 10.94 Only time will tell).
HP has reported that all the information and risk are subject to because not included in versions 10.00 in February. Yet I take the bet that if. This warning of HP is probably the only legal title.
I need not address in this article from Business Process T. (BPT) for the moment because it’s uncommon among French customers and above all a desire / wishes for HP to sell full containers (first desire of any software publisher after all).

Quality Center (QC) 10.00:
Regarding what Quality Center is, I refer you to my articles on tools for testing repositories / management as well as those on QC. The release date is scheduled for 31 January 09 and three packs will be distributed:

  • QC Starter Edition: Designed for a team of 5 single-project
  • Enterprise Edition QC: QC 9.2 equivalent current (TD for Quality Center)
  • First Edition: Designed for a team with needs such as advanced multi-project, high availability platform supporting QC, etc.

I will detail here only the Enterprise Edition / First of QC because it is where the real changes / new features.
QC Enterprise Edition / First, the modules present:

  • Requirements management
  • Test plan
  • Lab Tests
  • Risk based testing
  • Release management
  • Defect management
  • QA Lab Manager

The sentence shock input presentation by HP was « Mastering the chaos version requirements, tests and components”! Rather ambitious and shock, but see news (grouped by topic below).

Reporting:
Centralizing these unlike the current dashboard (9.2)

  • New module replacing the dashboard
  • Centralized reporting
  • All panels are centralized in the module
  • Creation of public view and private
  • Report possible multi-project
  • Take this version of reporting as the V1 from the old … Finalized dashboard module so.

Possibility to define a more complete test:

  • Risks and technical occupations ==> assigned to a functional complex – calculation of risk

Versioning: this module is not useful for a small project
Version Management requirements, tests (test sheets for example) and components:

  • Check-in and check-out
  • Comparison between the
  • Ability to return to a previous version
  • Can be activated at a project through the hotel (the new business administrator, therefore)
  • The versioning is of course to be taken into account before the project starts (part of best practices dear to CMMi and other ITIL)
  • Establishment of baselines (creating a picture of a set of project components), to mark / identify the milestones of the project. Example: requirements validated V1: establishing a baseline. It also allows you to freeze a configuration of testing association with a test campaign.
  • Guarantees to run the correct version vis-à-vis a test campaign
  • Comparison of baseline possible ==> identifying the elements that have changed

QC Requirements Management:

  • It would be a direct competitor tools like Doors, Req Pro and other Caliber
  • HP cites a 2008 report issued by Forrester and noting that the new management module requirements of HP is the first before all others. Hmm … I just think this kind of premature conclusion since the version that comes out in February and that results can be obtained after a few months of intense use in the real customers. A monitor then.

Other: template:

  • It is now (finally?) possible to define a project template and especially to use it and share it between many projects. The major fact is the possibility to update the template and distribute the update on the entire project implementing it. You should know that the current version 9.2 is only possible through internal development of each client.
  • Ability to setup and maintenance of centralized template
  • Broadcast « automatic » updates
  • Maintenance of template by administrators
  • Please note that this feature also joined the concepts of best practices advocated by CMMI and ITIL

Functional testing:

  • Output January 31
  • WinRunner is no longer included in this pack

Contained in the pack Functional testing:

  • Resource Management QTP:
  • Versioning
  • Tools Comparison

QuickTest Pro (QTP) 10.00:
Better reporting

  • Monitoring local system: this module allows RUN when scripts to monitor the implementation and some points. Specifically we can identify at what point and following the action script a problem occurs. For example, a peak CPU load generated by the action of a QTP script. This will help to strengthen links and interactions between the teams test and those in charge of performance tests. It should be noted that this function has been implemented by many customers through internal development. They will appreciate.
  • Improvement of the various GUI:
  • Tools management tasks (TODO)
  • Support for scripting
  • Export to DOC format and PDF reporting
  • Ability to attach screenshots
  • Direct access to the script from QTP reporting
  • Ability to compare two versions of scripts easily

My final impression is that QTP is transformed into CASE (Computer Aided Software Environment or AGL (Atelier de Genie Logiciel for French people)) but oriented tests. What I mean is that HP has incorporated many features to better script and more to help developers fully QTP scripts. I find it beneficial for all writers. Do not draw hasty conclusions and wait till the first returns of experience other than HP. Finally, synergy, linkages between QTP and QC seem also strengthened.

What about migration?
To migrate your versions to 10.00 you must already have version 9.0 (patch 26) and QC 9.2 (patch 12). Unable to migrate with older versions as these.
An upgrade tool is available on the HP site to help you with migration. But be careful if this works as the previous times you need to go through testing experts to help you because the migration tool from HP does not expect miracles and calls for the intervention of humans.
One last thing about the migration, if you go to QC 10.00 you should necessarily go to the 10.00 version of QTP.

WinRunner:
Do we collect on the body of this bloodless automation testing tool that was a forerunner in our industry. He well-deserved retirement. Rest In Peace WinRunner and thank you for everything.

  • It is no longer distributed with the pack functional testing
  • End 2009: End of the developments and patch
  • End 2011: The end

Goodies and “petits fours” (little cakes for corporate party in France):
And the goodies offered by HP for us to reward our time and attention? Well we had a pink plastic pen, a few blank sheets to the header of HP … and a book in English on the tests!
His name is « Optimize Quality for Business Outcomes – a practical approach to software testing » and this in its third edition. This is the first time I have heard of this book dealing with the tests. Below I list the main chapters:
1. What is the big deal about testing?
2. Testing the business requirements: start at the root of the problem
3. Test rules: build the backbone for effective testing
4. Test cases: let’s get down to the real stuff
5. Test optimization: balancing risk and effort
6. Why bother with non-functional testing?
7. Application security testing: the next frontier
8. Test sourcing: how outsourcing improves cost effective testing
9. Successful goal-driven approach KPI
10. Getting started: putting it all together
11. Appendix A – Common test techniques
12. Appendix B – HP application quality management solutions introduction and overview
13. Appendix C – Verification
14. Appendix D – Naming conventions

I try to read this book quickly and I will make my opinion, soon.

And then?
Ultimately, HP’s strategy is to play together in the editing software to expand its functional and its turnover. What is a healthy and able to provide end users with better service and services companies expanding their services (with a contribution of value added greater than today).
However, HP blithely tramples the toes of many competitors / software editor. So publishers with tools for managing requirements and configuration management / version will inevitably their market shares reduced inexorably by HP. As inexorable as desertification in Africa? Not so on this because, take for example publishers management software requirements, their products will not be dedicated more complete than that of HP. It remains to be seen more fully the choice of HP doing in this area and the effort to test them in real life!