La Newsletter d'acial

Mars 2010

L'EDITO

UNE BUSINESS UNIT DEDIEE AUX SECTEURS
BANQUE/ASSURANCE/MUTUELLES

LES ACTUS

LE 1er PETIT DEJEUNER DU
«CLUB ACIAL DU TEST LOGICIEL»

Le 1er petit-déjeuner du «CLUB ACIAL DU TEST LOGICIEL» a eu lieu le 12 mars dernier sur le thème :

"LES APPORTS DE LA CERTIFICATION CFTL, REALITES D'AUJOURD'HUI ET BENEFICES DE DEMAIN"

Première édition d'un cycle de conférences sur le test logiciel, ce petit déjeuner a été l'occasion de découvrir comment la formation et certification des équipes aux méthodes de tests peut faire passer un cap en développant un langage commun.

Avec la participation de PAC qui a fait une présentation sur l'état du marché, ce petit déjeuner a également donné la parole à Bernard Homes, Président du CFTL, et à nos experts qui ont fait partager nos bonnes pratiques, méthodologies, outils, et leurs retours d’expériences sur des projets que nous avons mis en œuvre.

A noter sur vos agendas : prochain petit déjeuner du "Club Acial du test logiciel" : le vendredi 7 mai 2010.

ACIAL RENFORCE SA DEMARCHE ITIL
EN SIGNANT UN NOUVEAU PARTENARIAT AVEC MPROOF

MProof est l’éditeur néerlandais de Clientele ITSM, solution de gestion des services IT dédiée au mid-market. Dans le cadre de ce partenariat Acial, qui utilise déjà le logiciel Mproof en interne, est revendeur de la solution Clientele ITSM.

Centrée sur les meilleures pratiques industrielles définies par ITIL, cette solution apporte une réelle valeur ajoutée dans la démarche d’amélioration de la performance et de la qualité des SI pour nos clients.

Dans le cadre de ce partenariat, MProof formera nos équipes sur l’implémentation et la mise en œuvre de Clientèle ITSM et nous travaillerons ensemble à l’élaboration de nouvelles offres.

ACIAL ASSURE LA RECETTE FONCTIONNELLE DE L’OUTIL CRM
DE LA CHAMBRE DE COMMERCE ET D’INDUSTRIE DE TOULOUSE

La CCI de Toulouse a choisi de déployer CLIaNTIS, un outil de gestion de la relation client (CRM) partagé par l’ensemble des 120 collaborateurs de sa Division « Appui aux Entreprises ». La mise en place du CRM dans cette division a pour but de mieux connaître les entreprises, mieux agir dans leur intérêt et celui du développement économique du département et d’optimiser le pilotage de ses activités.

Le projet, d’une durée de 6 mois, a pour objectifs de valider l’utilisabilité de l’outil CRM, de garantir la conformité des livraisons, de corriger toutes anomalies bloquantes et d’assurer le démarrage du déploiement dans les meilleures conditions.

TRACE ONE, LE SPECIALISTE DES PLATES-FORMES E-COLLABORATIVES
A CHOISI ACIAL POUR TESTER SES DEUX NOUVEAUX PORTAILS

NOUVEAUX SERVICES, NOUVEAUX ENJEUX POUR
LA DIRECTION DES JOURNAUX OFFICIELS

La Direction des Journaux Officiels (DJO) s’est impliquée avec détermination dans la réforme de l’Etat. Cette démarche s’est appuyée sur les opportunités offertes par les nouvelles technologies : plus que d’autres administrations, les Journaux Officiels ont dû se réinventer pour intégrer les progrès des systèmes d’information.

En 2008, la DJO a mis à la disposition des citoyens et des professionnels plus de 30 000 textes juridiques nouveaux, consolidé près de 50 000 articles de loi ou de règlements, mis en ligne 30 000 arrêts de jurisprudence, diffusé 6 millions et demi d’annonces légales ou commerciales.

La DJO a confié à Acial l’assistance à la recette du Nouveau Système de Production du service de la rédaction. Un projet de 4 mois pour éprouver la fiabilité du système qui doit garantir une sécurité optimale afin d’assurer la parution quotidienne et dans les délais impartis du JOLD. Acial aidera la DJO à mieux appréhender et à optimiser les procédures définies et accompagnera les utilisateurs issus de profils métiers différents lors du basculement du JOLD dans le nouvel environnement technique.

ACIAL, SPONSOR …

DE LA JOURNEE FRANÇAISE DES TESTS LOGICIELS LE 30 MARS 2010 A PARIS

Comme chaque année, le CFTL organise la Journée Française des Tests Logiciels qui se tiendra le 30 mars 2010, au CAP 15, Quai de Grenelle, Paris 15ème. A cette occasion vous pourrez assister à des présentations et conférences sur deux grands thèmes: les aspects de gestion de tests et les retours d'expérience.

Pour plus d’information : www.cftl.net

DE LA CONFERENCE IQINITE SUISSE LE 15 JUIN 2010 A GENEVE

La conférence iqnite (anciennement Software & Systems Quality Conference) est un des événements les plus importants pour la communauté du test de logiciels et de la gestion de la qualité. S’y rassemblent les acteurs-clés et les experts qui présentent les dernières tendances, partagent leurs expériences.

Pour plus d’information : www.iqnite-conferences.com/iqnite-fr/index.htm

^^

LA PAROLE A …

BERNARD HOMES, PRESIDENT DU COMITE FRANÇAIS DES TESTS LOGICIELS (CFTL)

Amélioration des tests : une urgence économique !

Laissons la parole à Bernard Homès, Président du CFTL 

Les faits parlent d’eux-mêmes

Les développements logiciels coûtent de plus en plus cher. Avec une part correspondant à 30%, voire 50% du coût total de développement, les tests en sont une partie non négligeable. Malgré de nombreux efforts, la qualité des logiciels ne semble pas s’améliorer pour autant. L’actualité récente (plusieurs millions d’utilisateurs de cartes bancaires allemands pris en otage en Janvier 2010 ; le fleuron d’Airbus obligé de faire demi-tour le 20 novembre 2009 pour une panne de pilote automatique, etc.) nous le rappelle fréquemment.

Selon des études récentes, le niveau de qualité des logiciels livrés est encore fortement améliorable, les meilleures sociétés ne découvrant et ne corrigeant que 85% des défauts et livrant, avec le logiciel les 15% de défauts restants. Dès que l’on parle de milliers de défauts, 15% devient un nombre important.

L’augmentation sans cesse croissante de la complexité des applications et du nombre d’interactions entre les logiciels (p.ex. Cloud, SaaS, etc.) fait qu’un défaut dans un autre composant peut influencer le fonctionnement de votre propre logiciel ou système. Pour vous en prémunir, il est nécessaire de faire des tests exhaustifs, ce qui est difficilement justifiable économiquement, voire impossible en termes de délais et de charge.

Dans un contexte de compétition internationale, de recherche de rentabilité et de compétitivité, il est indispensable d’améliorer l’efficacité des processus de développement et de test. L’efficacité des développements logiciels a fait l’objet de nombreuses actions ; nouveaux langages, de nouveaux paradigmes et nouvelles méthodologies. Or, la qualité des logiciels ne s’est pas améliorée sensiblement, les coûts ont continué à croître, les délais à s’allonger. « Que fait la qualité, à quoi servent les testeurs ? » est une question qu’on est en droit de poser.

La professionnalisation des tests

Depuis la publication des premiers ouvrages de vulgarisation sur les tests il y a plus de 30 ans, de nombreux milliards de dollars (puis d’euros) se sont envolés en fumée, reflétant frustration des utilisateurs, exaspération des testeurs et nuits blanches des développeurs. Et cela, malgré les nombreux livres de référence et outils de tests existant à ce jour.
Dans le même temps, des organismes se sont penchés sur l’amélioration des processus et ont proposé des programmes d’évaluation (CMMI, SPICE, ISO9000, etc.) qui ont démontré leur intérêt économique, entre autre l’aspect d’amélioration continue des processus, seul à même de proposer une réduction des coûts à long terme.

Les méthodes d’amélioration des processus de test

L’efficacité des processus et techniques de test est dépendante du contexte où ils sont utilisés, et seule une amélioration continue garantit leur efficacité accrue. L’amélioration des processus de test, pour en réduire les coûts et la durée ou augmenter leur efficacité, est un objectif affiché par tous. Cependant, ceci ne peut se faire qu’avec un niveau de référence à partir duquel comparer les évolutions.

Plusieurs méthodes d’amélioration de processus existent. Elles se regroupent en deux familles : celle à modèle de référence externe où l’on compare les processus par rapport à un référentiel idéal (p.ex. TPI, TMMI, CMMI) ; ou celle à modèle de référence interne, où le référentiel est la société elle même, et ses propres processus (p.ex. IMPROVE, PLAN, CTP, STEP, ODC).

L’amélioration des processus basée sur un référentiel externe s’appuie sur des processus établis. Il est donc simple de faire appliquer ces méthodes toutes faites. La mise en œuvre cependant peut ne pas correspondre aux attentes et une autre question peut se poser : quelles actions d’amélioration envisager après que le référentiel externe ait été complètement implémenté ?

L’utilisation d’une méthodologie basée sur l’analyse du référentiel interne de l’entreprise est automatiquement adaptée aux besoins de celle-ci, après une évaluation (un audit) des processus de test et de développement existants, de leur rentabilité respective (en terme de coût, de génération de défauts et d‘efficacité de détection). L’évaluation des processus et leur pertinence, l’identification des processus à améliorer, la sélection de ceux à améliorer en priorité, et la préconisation d’actions, nécessitent une compétence pointue et une expérience étendue de la part de l’acteur. De tels niveaux de connaissance requièrent des consultants sénior expérimentés. Si leur coût journalier peut paraître élevé, les améliorations qu’ils préconisent étant adaptées aux besoins de l’entreprise, leur rentabilité à court terme est souvent fort élevée.

L’évaluation de la rentabilité

L’évaluation de la rentabilité des processus doit étudier, outre les coûts de réalisation et le nombre de défauts identifiés, le nombre de défauts qui échappent au processus de détection. Il faut donc prendre en compte les coûts des défauts (et tous les coûts associés à leur correction), lesquels augmentent en cas de détection tardive.
Combien de sociétés évaluent actuellement les coûts de leurs défauts selon le moment où ils sont découverts ? Pourtant ces informations sont disponibles, il suffit de les mesurer.

Combien de responsables de développement sont en mesure d’identifier l’origine d’un défaut, de l’associer à un processus de développement, et de proposer des actions d’amélioration de façon à éviter une répétition de ce défaut dans le futur ? Combien sont en mesure de fournir une évaluation statistique liant les défauts identifiés aux processus de développement qui sont à l’origine de ces défauts ?

Des axes d’amélioration

Plusieurs ouvrages de référence mettent clairement en avant l’efficacité des processus de test statiques (revues, inspections, analyses de code) et le besoin d’améliorer la qualité des exigences, comme moyens d’atteindre rapidement un niveau de qualité adéquat des développements. Une étude récente portant sur plus de 12 000 sociétés a démontré qu’aucune technique individuelle de test ne permettait de trouver plus de 30% des défauts d’une application. Il est donc recommandé de mettre en œuvre plusieurs techniques complémentaires pour assurer une efficacité de détection autour de 85-90%.

Quels processus améliorer ?

La sélection des processus à améliorer doit se faire selon leur rentabilité. Celle-ci s’évalue, d’une part en fonction des améliorations immédiates fournies (défauts supplémentaires détectés), et d’autre part en fonction des améliorations induites dans les autres processus.

Exemple : un éditeur connu a réussi, par l’application d’inspections formelles (analyse statique) à trouver 50% de défauts de plus que lors des releases précédents, réduisant la durée totale des tests de 15% et la charge de test dynamique de 75%.

Mesurer et améliorer la rentabilité des processus du test doit devenir un préalable

La détection des défauts et leur correction sont les activités les plus chères du cycle de développement de logiciels. Toute amélioration de ces processus se traduira directement par des réductions de coût, par des développements de qualité et une diminution du nombre de défauts détectés par les utilisateurs.

Pour les améliorer, il est important de mesurer les activités de tests, et aussi toutes les autres activités liées au cycle de vie des logiciels, depuis les exigences jusqu’à la maintenance, au support hotline et au SAV, car l’amélioration des processus de test influence aussi ces autres processus. Une mesure en termes d’impact et en termes de volumétrie, aide à déterminer les processus à améliorer en priorité.

La recherche des origines des défauts (Analyse des Causes Racine) permet d’identifier les processus défaillants, à l’origine des défauts. Des méthodes d’amélioration des processus, intégrant les aspects systématiques et statistiques, permettent de garantir un taux de retour sur investissement supérieur aux meilleures sociétés cotées en bourse.

Parce que les tests représentent entre 30 à 50% des coûts de développement, leur amélioration est une urgence économique justifiant un regard appuyé de la part de la direction de nos entreprises. Une amélioration itérative de la rentabilité des processus de test permettra de montrer la maturité de notre profession, notre professionnalisme et notre valeur ajoutée.

^^

LE ZOOM SUR...

LES FREINS ORGANISATIONNELS A LA QUALITE LOGICIELLE DES SI

PEUT-ON LEVER LES FREINS ORGANISATIONNELS A LA QUALITE LOGICIELLE DES SI ?

Par Bertrand Cornanguer – Consultant sénior chez acial

Des objectifs différents et pas de gestion globale de la qualité

Dans les grandes sociétés, les services informatiques ont chacun leurs objectifs, MOA, développement-études, production, et dépendent d’une DSI dans laquelle la qualité n’est pas gérée de manière transverse. Pour beaucoup encore, faire de la qualité, c’est faire des tests fonctionnels avant livraison en production. Plus les anomalies sont détectées en tests, plus les budgets de développement augmentent… Pourquoi ne pas utiliser ces enveloppes pour industrialiser la qualité logicielle sur tout le cycle de développement, et même sur le cycle de vie du système d’information ?

Une fois le système mis en production, les activités de gestion des incidents prennent le relai, et sont assurées par des personnes n’ayant pas de périmètre d’action au niveau des développements.
Pourquoi ? Parce que les budgets sont différents. Certains considèrent que si des anomalies logicielles surviennent, c’est que le processus de fabrication est défectueux. Or le processus de fabrication logicielle est souvent une suite d’activités indépendantes non pilotée par la qualité.

Dans certains appels d’offres, les missions de Tierce Recette Applicative et de Tierce Maintenance Applicative sont séparées, ce qui n’est malheureusement pas toujours le cas. Mais même dans ce cas, il manque le pilotage transverse de la qualité et l’on peut voir les deux entités « s’étriper » au lieu de travailler ensemble à l’élaboration d’un processus industriel.

Aujourd’hui, la qualité logicielle pâtit de mises en production de systèmes non conformes aux besoins du client. Peut-être certains préfèrent prendre ou cacher ce risque plutôt que d'informer et de décider de retards dans la planification ?

Des référentiels Qualité créant des inégalités

Dans les grandes sociétés, on découvre des organisations qui ont évolué au fil du temps, avec des référentiels Qualité spécifiques et indépendants les uns des autres (ISO, ITIL, CMMI).

La norme qualité organisationnelle ISO9000 est destinée à rassurer le client, mais peut être déployée sur une partie seulement de l’entreprise. Par exemple, les services administratifs en relation avec les clients pourront être ISO9000, avec des processus métier, des procédures réfléchies et des indicateurs de non conformités pertinents et suivis. Il est probable que les services de production informatique ou d’infogérance aient également mis en place des processus organisationnels basés sur ITIL car ils communiquent directement avec les utilisateurs finaux.

Mais qu’en est-il de la conception et de la réalisation informatique ? Parfois, ces services sont sous-traités en tout ou partie, obéissent à des règles particulières, et règnent sur les jalons du processus de fabrication informatique car sans eux point de logiciel.

L’idéal serait de mettre en place une stratégie assurant la qualité tout au long du processus de fabrication logiciel. Les projets sont régis par le triptyque Qualité-Coûts-Délais. Il est donc nécessaire en début de projet d’identifier les risques et les impacts des pannes sur le système à développer, et de programmer à quelles phases du processus de développement et par quelles entités ces risques seront couverts par des tests.

Une stratégie qualité globale dépassant les clivages organisationnels et la domination de la technologie

Plus tôt des défauts sont découverts, moins le projet coute cher. Cette stratégie vise à assurer que le client sera satisfait. Par le biais des revues et d’une gestion des exigences, on pourra s’assurer que le client a bien énoncé son besoin et que les spécifications le traduisent explicitement pour des caractéristiques fonctionnelles et non fonctionnelles. En effet, vous n’attendez pas seulement de la voiture que vous achetez qu’elle fonctionne, mais qu’elle soit également confortable, attrayante, fiable….

A chaque activité de conception ou de réalisation, correspond une activité de test. Une fois développé, un composant sera testé unitairement afin d’éliminer les erreurs de programmation. Le test unitaire est aidé par l’analyse structurelle que délivrent les logiciels d’analyse statique ou de métrologie de code. Lors des tests d’intégration, les intégrateurs testent les interfaces entre les composants unitaires ou les applications.

Au final, le client reçoit un logiciel conforme aux spécifications et réalise des tests d’acceptation correspondant à son cahier des charges. A ce niveau, les anomalies doivent être anecdotiques.
Mais qui est en charge de la stratégie d’assurance qualité ?

Peut être le chef de projet ? Mais en a-t-il le temps et le savoir ? Il existe des sociétés dans lesquelles le chef de projet n’a pas de formation qualité logicielle et fait la part belle à la technologie. Pour certains, faire de la qualité logicielle c’est tester avant de livrer le client. Les jalons sont prévus avec une faible marge de sécurité que chaque intervenant cherche à consommer pour ses besoins. Dans ces organisations, les tests sont appelés recettes. Ils ont pour seul objectif de trouver des défauts. Parfois les recettes sont programmées pour une durée fixe !

Et les tests de production ? Saviez vous qu’une fois développé, le logiciel continue son cycle de vie et quitte le cycle de développement ? Les services de production doivent accepter opérationnellement le nouveau système. Tests de backups, crash tests, performances et autres tests techniques prennent du temps et sont différents suivant leurs types et le système d’exploitation sur lequel ils fonctionnent.

C’est dès le lancement du cycle de développement d’un produit, que la politique qualité doit être mise en place. Pour cela, il faut définir comment les phases de test seront organisées, quels seront leurs objectifs et leur budget.
Même dans le cas de la sous-traitance, le maître d’œuvre devra prouver que les tests correspondant à son niveau ont été réalisés. Cela n’est possible que si un contrat, une norme ou une charte l’y oblige.

La difficulté de la transversalité

Les services de qualité transverses se heurtent à l’hégémonie de certains responsables de développement. Ces derniers considèrent que le développement logiciel est une boite noire et espèrent toujours avoir plus de temps que prévu pour développer. Tout comme les individus peuvent rencontrer des difficultés à travailler en équipe et préférer la séparation et la distribution individuelle des tâches, les services préfèrent travailler séquentiellement.

Si le suivi qualité n’est pas assuré et les responsables des autres activités du processus non informés, le client demande la livraison de son logiciel alors que ce dernier n’est pas terminé. C’est l’effet « tunnel » qui peut provenir d’un projet de développement au forfait pour lequel il n’y a pas de suivi hebdomadaire de l’avancement. Dans certains cas, le client en arrive à suppléer le maître d’œuvre en réalisant lui-même les tests !

Les principaux freins à la qualité logicielle engendrés par les organisations sont :

• Les contrats qui limitent les engagements des développeurs
• Les jalons que certains rebutent à décaler
• Les processus non décrits dans lesquels personne ne sait qui fait quoi quand et comment
• La non prise en compte des politiques de qualité par les chefs de projet.
• Le refus d’accepter l’ingérence des services qualité transverses dans les projets de développement
• Les recettes vues comme des projets isolés non inclus dans une stratégie qualité globale.
• Les difficultés de communication dues à l’éloignement des équipes.
• La nécessité de produire des retours sur investissement prévisionnels avant de lancer un cycle d’amélioration du processus de fabrication logiciel.

Lever les freins en créant la « charte de bonne conduite du développement logiciel »

Pourtant notre industrie manufacturière a depuis longtemps levé ces freins. La conception et la fabrication d’un logiciel peuvent suivre les même processus que la conception et la fabrication d’un phare automobile ou d’un ordinateur.

• Dans ce cas, pourquoi ne pas proposer un encadrement de projet composé d’ingénieurs et responsables ayant un vécu industriel ?
• Pourquoi ne pas créer un standard de contrat de maîtrise d’œuvre informatique assurant la qualité logicielle ?
• Pourquoi ne pas proposer un standard d’appels d’offres dans lequel le client devra fournir un cahier des charges exhaustif de type IEEE830 avant qu’un maitre d’œuvre puisse lui faire une offre de service de développement ?

Assurons le développement durable et créons et adhérons aujourd’hui à la « Charte de bonne conduite du développement logiciel ».

^^

ACIAL EN PRIVE

EN PRIVE AVEC ALEXANDRE DANTIER, CHEF DE PROJET RECETTE CHEZ ACIAL

Harmonisation du langage des tests : un nouvel esperanto serait-il né ?

Par Alexandre Dantier, chef de projet Recette chez Acial

Ah qu’il est dur d’être testeur de nos jours !

A chaque nouveau projet, il faut se réapproprier le langage associé à la qualification : qu’est-ce qu’un cas de test, qu’est-ce qu’un scénario … En plus des difficultés d’adaptation, voire de traduction, s’ajoute parfois l’incompréhension entre les différentes parties prenantes d’un projet de qualification.

L’incompréhension c’est le retard, et en général, les phases de test ne se permettent pas ce luxe.

Or depuis quelques années, le CFTL (Comité Français du Test Logiciel) est parti en croisade afin d’harmoniser autant les pratiques que le langage du test.

Un nouvel Esperanto serait-il né ?
Une seule voie, que dis-je, une seule voix par laquelle tous les acteurs - MOA, MOE et testeurs, pourraient communiquer et se comprendre enfin, afin de travailler plus efficacement.
Pour vous donner un exemple, j’officiais en tant qu’expert outil et qualification dans un projet de mise en place d’un outil de gestion de test. Mes deux interlocuteurs principaux étaient, d’une part le responsable de la qualification, et d’autre part le chef de projet.

L’outil mis en place depuis peu fournissait ses résultats au fil des exécutions de tests : « Passed » pour « passé avec succès », « Failed » pour « en erreur », « No Run » pour « non débuté » et « Not completed » pour « non terminé ».
Bien que ces termes soient suffisamment explicites pour le responsable de qualification, le chef de projet trouvait de l’ambiguïté dans ces différents labels et surtout dans la désignation « Passed ».

Pour lui, un test dit « Passed » indiquait un test qui s’était effectué sans aucune sanction de réussite ou d’échec, et ceci malgré la petite coche verte bien visible à côté du test dans l’outil.

La discussion s’engagea donc entre le responsable de qualification et le chef de projet sur la légitimité de ce statut. Le chef de projet prétextait donc que ce statut n’était pas suffisamment clair, notamment pour les tableaux de bord des comités de pilotage, et le responsable de qualification indiquait qu’il fallait suivre les propositions de l’outil, étant donné que sa fonction était la gestion des tests.

La discussion devenant de plus en plus animée, les deux hommes se sont retournés vers moi, l’expert en qualification afin de mettre un terme à ce désaccord.

En quelques clics de souris, je téléchargeais le glossaire du CFTL et recherchais la définition de « Passed ». La réponse fut sans appel :

Critère passe/échec : règles de décisions utilisées pour déterminer si un élément de test (fonction) ou caractéristique a passé avec succès ou échoué un test [IEEE 829]
Le CFTL avait parlé. Le statut « Passed » correspond bien à une exécution avec succès d’un test suivant la norme IEEE 829.
La discussion fut close, et hormis le fait d’avoir donné raison au responsable de qualification, le CFTL, par son glossaire commun du langage du test, a apporté l’accord et l’adhésion des deux parties.
CQFD, euh pardon CFTL.

Alexandre Dantier - Chef de projet Recette chez Acial.

^^

EN BREF !

ON EN A PARLE DANS LA PRESSE !

Vous trouverez ici quelques uns des articles qui sont parus sur Acial :

CIO online le 14 décembre 2009
« CFTL, c’est franchement ton langage ? »
Une tribune d’Alexandre Dantier, Chef de projet recette chez Acial.
Lien de l'article: ici

01 Informatique 7 janvier 2010
Acial propose une formation pour se préparer à la certification des tests (CFTL/ISTQB)

Secteur Public.fr le 25 janvier 2010
Acial en mission à la CCI de Toulouse pour assurer la recette fonctionnelle de son outil de CRM.

OVS - Officiel des Vars et des SSII en février
Encourager la qualité logicielle des SI

Artesi-idf.com 26 janvier 2010
Acial assure le contrôle du portail documentaire du musée du quai Branly
Lien sur l'article: ici

^^

LES LIENS DU METIER DE LA QUALITE LOGICIEL

Cette rubrique a pour objet de vous faire découvrir des portails, des blogs, des sites institutionnels ou des media qui touchent de prés ou de loin au monde de la Qualité logiciel. N’hésitez pas à nous en faire découvrir d’autres ; nous les présenterons dans la prochaine newsletter !

Nous vous conseillons également le livre se Bruno Legeard aux Editions Dunod« Industrialiser le test fonctionnel :
Des exigences métier au référentiel de tests automatisés »

^^

A la prochaine édition !

Acial

PERFORMANCE & QUALITE
DES SYSTEMES D’INFORMATION
20 rue d’Athènes - 75009 Paris
Tel : +33 1 55 33 52 40
Fax : +33 1 55 33 52 41
Mail : askme@acial.fr
Web : www.acial.fr

^^