Please reload

Posts Récents

Il y a dix ans, je sortais du monde industriel et partais faire un DESS en Qualité et Sureté de Fonctionnement des Systèmes Informatiques à l’ISTIA d’...

Faut il avoir peur du mot "Exigences" ?

22/09/2014

1/1
Please reload

Posts à l'affiche

QUESTIONS A SE POSER POUR DEPLOYER LES TESTS A L’ECHELLE D’UNE ORGANISATION

Après en avoir pris la décision, mettre en œuvre les tests dans une organisation nécessite une connaissance approfondie du sujet. Voici des questions auxquelles il faudra répondre.

 

Qui sont les acteurs concernés par les tests ?

  • La direction de l’organisation qui a défini

    • la politique, c'est-à-dire pourquoi il y a des tests, comment elle va vérifier que cette politique est respectée et quels moyens elle met en œuvre.

    • La stratégie de tests, c'est-à-dire comment elle compte le faire

  • Les membres des services qualité iSO9000 ou autres qui veillent au respect des activités projet et des livrables associés.

  • Le métier ou ses représentants qui ont émis un besoin. Ils ont la charge de valider les fonctions développées ou intégrées.

  • L’exploitation qui assurera la disponibilité des systèmes et qui doit valider que les livraisons respectent leurs normes ou catalogues d’exigences d’exploitation et que le système se déploie sans anomalie.

  • La direction de projet qui suit la mise en œuvre des programmes/Projets pour leur client, le ou les sponsors qui proposent des solutions logicielles, anticipent les besoins. Ils auront donc des actions sur la validation d’exigences projet, le respect des calendriers, la qualité des livraisons et le cout de la mise en œuvre. Comme ces personnes ont une vision globale du projet, Les documents de stratégie, plans de tests maitre et de niveau devront donc être partagés avec eux. Avoir leur écoute et accord permettra de mettre en place un suivi transverse des tests allant du cadrage jusqu’à l’acceptation métier. Sinon, il risque d’y avoir une frontière entre les tests de la maitrise d’œuvre et ceux de la maitrise d’ouvrage/métier. En effet les MOE éprouvent souvent des difficultés à rendre leurs activités de testing transparentes et à avoir la confiance des MOA.

  • Le chef de projet qui a en charge de livrer un produit de qualité dans des délais pour un cout donné. Malheureusement le chef de projet est souvent pris dans des considérations plus générales que les tests. Même les plus formés au pilotage de projet par la qualité rencontrent souvent les affres des réunions de cadrages, les problèmes de ressources, d’ego de clients/Métier/MOA, les plans d’assurance qualité avec les fournisseurs, le cycle de vie du projet, l’agilité, l’argumentation sur les charges de développement (il faut bien produire avant de tester..). Donc ce chef de projet est débordé et s’il a la responsabilité des tests, un chef de projet de tests dédié lui permet de se focaliser sur les actions premières pour lancer son projet.

  • Le chef de projet de tests peut lui se concentrer sur les activités de testing au nom de l’organisation et pour le chef de projet. Il porte les activités de tests, voire l’assurance qualité pour le projet ou un niveau de tests. En effet son activité peut concerner un projet de A à Z, du cadrage aux acceptations opérationnelles et métier, ou bien un niveau comme l’intégration dans le SI ou un domaine d’applications. C’est lui qui mettra en garde le chef de projet sur des plannings de développements trop optimistes ou des lots d’évolutions ou de nouvelles fonctionnalités à développer trop importantes, non loties.

  • Les testeurs qui collaboreront à l’élaboration des plans de tests, analyseront et prépareront les tests. Ceux qui les exécuteront s’ils sont différents.

  • Les intégrateurs dans le SI qui suivant les organisations peuvent avoir des équipes dédiées.

  • Le fabriquant du système logiciel qui réalise et livre le client

    • Les testeurs qui vérifieront que tout fonctionne avant de livrer le client.

    • Le développeur qui créera le logiciel et exécutera les tests unitaires (nouveauté et non régression)

  • Les personnes support comme les

    • spécialistes méthodes, normes et outils de tests

    • gestionnaires d’environnements de tests, spécialistes des jeux de données de tests

    • Responsables de la gestion de configuration

  • Les services/sociétés extérieures qui exécutent des Tierces Recette Applicatives à différents niveaux

 

Que vais-je tester ?

Ce qui doit être testé en termes de modules/programmes/systèmes et en termes de types de tests. Qu’est-ce que j’attends de mon système logiciel, coté Métier, coté exploitation, coté développement ?

Cela est défini dans la norme ISO9126 qui a évolué depuis en ISO Square 25000. Pour un niveau donné, il convient de définir les caractéristiques Qualité qui peuvent être vérifiées ou validées pour des parties complètes ou des parties de logiciels. Planifier consistera à définir quels types de tests il faudra réaliser pour répondre à des objectifs de niveau de tests.

 

Ou vais-je le tester ?

Centres de compétences de tests, TRA, centres de services, plateau projet. Ou les tests vont être préparés, implémentés, exécutés dépend des organisations. Certaines comme de grandes banques alliées à des SSII internationales ont choisi de délocaliser les tests dans le monde, en off-shore (Inde Mumbai par exemple), Near shore (Afrique du nord, On shore : villes de province pour les projets Parisiens ;).

 

Quand testerais-je ?

Souvent mis avant le reste, le Quand est un élément de communication essentiel. Faire un calendrier en accord avec un plan de version SI est difficile. Le suivre encore plus.

Comment le chef de projet de tests peut-il dire quand les tests seront préparés, exécutés s’il existe des incertitudes quant aux plannings de développement ?

Souvent le chef de projet commence par planifier en faisant un retro planning, en fonction d’un plan de version SI par exemple, de la date de livraison d’un projet avec lequel il est en adhérence, ou de la date de mise en production demandée par un service Marketing ou un client.  Puis il cherche à intégrer dans les délais défini les activités liées aux tests. Une fois cela fait, en fonction de l’estimation de la charge de tests effectuée (voit le chapitre Estimation des charges), il définit le nombre de ressources nécessaires.

 

Comment vais-je tester ?

 Quelle stratégie de tests dois-je mettre en œuvre ? Il y a-t-il une stratégie à appliquer pour mon domaine fonctionnel par exemple ? Devrais-je suivre une norme industrielle ?

  • Les techniques de tests concernent les analystes de tests,

    • Les plans de tests de niveau les préciseront

  • Les approches de tests concernent les chefs de projet de tests

    • Les plans de test maitre et de niveau les détailleront

  • Les stratégies de tests concernent les domaines fonctionnels/Pôles applicatifs/organisations. 

Pour certains projets, il faudra respecter une norme sur les systèmes à sécurité critique comme la DO178 pour l’avionique ou l’ISO 26262  dans l’automobile. Ces normes ont un impact fort sur les tests car elles précisent la couverture de test attendue.

Pour d’autres, les chefs de projet de tests définiront en accord avec les parties prenantes, le délicat dosage qu’ils devront faire entre les

  • stratégies offensives (mettre en œuvre les des revues par exemple) ou défensives,

  • les approches analytiques basées sur les risques « produit »,

  • méthodiques basées sur des listes contenant des points à vérifier,

  • heuristiques comme la mise en œuvre de tests exploratoires,

  • stochastiques basées sur le principe du regroupement des défauts, la gestion des incidents et des problèmes connus.

 

Combien cela me coûtera t’il ?

L’estimation des tests est un point important qui peut être traité en deux fois.

  • Lors du cadrage puisqu’il est nécessaire de fournir des prévisions pour obtenir les budgets. Cette évaluation se fait souvent à partie d’abaques de projet antérieurs. Ces abaques peuvent être formalisés dans des matrices de chiffrage ou bien fournies par des experts selon leur expérience.

  • Lors de l’affinage des tests pour un niveau de tests pour définir les objectifs par objet de tests et caractéristique Qualité à vérifier (évolution, fonctionnalité). Cette estimation se fait avec le testeur qui a la connaissance précise des tâches à réaliser et est pondérée avec les facteurs de qualité du processus.

L’investissement est à mettre en balance avec le coût de la non qualité. Pour rappel, cette non qualité comprend

  • les coûts de supports (Détection, gestion, mise en œuvre d’une solution palliative),

  • Les coûts de maintenance corrective (débogage, codage, tests, intégration, reploiement en production).

  • Les coûts de perte de productivité des utilisateurs,

  • Dans le cas où le logiciel sert à fabriquer des produits manufacturés, le coût engendré par la non qualité des produits fabriqués.

 

Pourquoi se poser ces questions ?

Parce que le jeu en vaut bien la chandelle. Vais-je perdre mes clients si je livre un système logiciel qui n’assure pas une disponibilité 360/365 jours par an. Vais-je atteindre la vie de personnes si je leur livre des systèmes défaillants ? Ou bien suis-je une entreprise qui offre un service exclusif et dans ce cas le risque pour moi est de voir les utilisateurs mécontents attaquer mes sites WEB et me critiquer dans la presse ?

Les risques liés aux non fonctionnements sont avérés pour tous les projets logiciels. Maintenant, il faut que les parties prenantes en aient conscience. Il faut qu’un médiateur explique aux clients, développeurs, qu’entre le développement et l’acceptation utilisateur, de nombreux tests sont à réaliser pour couvrir des risques, comme de voir un client insatisfait. Ces tests sont regroupés par niveau:

Du coté de la partie en charge de construire et de délivrer le produit :

  • Les tests de composants qui vérifient que les composants développés respectent les spécifications techniques à destination du développeur

  • Les tests d’intégration de composants qui

    • vérifient les interfaces entre programmes Cobol, modules java, DLL Windows…,

    •  vérifient les liens à partir des Dossiers d’architecture détaillés.

  • Les tests systèmes réalisés par le fournisseur pour vérifier que ce qui a été développé correspond bien aux spécifications générales et que toutes les caractéristiques Qualité sont bien prises en compte.

 

Coté client en charge de l’intégration du système développé dans son environnement

  • Les Tests d’intégration pour vérifier l’interopérabilité des systèmes, les interfaces entre elles.

  • Des tests système qui vérifient que le système complet répond aux caractéristiques Qualité attendues

  • Les tests d’acceptation utilisateur qui valident la concordance avec l’expression des besoins

  • Les tests d’acceptation opérationnelle qui valident que le système développé respecte les normes/exigences d’exploitation.

Pour chaque projet, il conviendra de mettre en œuvre une logique industrielle adaptée. En fonction des systèmes développés, des organisations, des cycles de développement, de la maturité des organisations, il convient de rajouter/préciser des niveaux de tests de tests ou de les supprimer.

Mettre en place les tests dans une organisation n’est pas chose aisée et cela nécessite de faire appel à des professionnels du test. C’est pour cela que l’ISTQB a défini plusieurs niveaux de certification qui assurent ce savoir-faire.

 

 

Partager sur Facebook
Please reload

Retrouvez-nous
Please reload

Archives
  • Facebook Basic Square